Videotext application crashes the kernel due to DVB-demux patch

Hi,

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

http://www.mail-archive.com/[email protected]/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 <[email protected]>"

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!

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 12 lines · 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/[email protected]/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.

Quoted 5 lines

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

Quoted 52 lines

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

Quoted 19 lines · Chicken Shack

Quoted 12 lines

Hi,

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

http://www.mail-archive.com/[email protected]/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.

Quoted 5 lines

Regards

CS

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

Quoted 60 lines

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

Quoted 52 lines

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

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:

Quoted 99 lines · Andy Walls

Quoted 19 lines · Chicken Shack

Quoted 12 lines

Hi,

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

http://www.mail-archive.com/[email protected]/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.

Quoted 5 lines

Regards

CS

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

Quoted 43 lines

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

Quoted 35 lines

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.

Quoted 7 lines

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.

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

Thanks for your engagement, Andy!

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

Quoted 100 lines

Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:

Quoted 99 lines · Andy Walls

Quoted 19 lines · Chicken Shack

Quoted 12 lines

Hi,

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

http://www.mail-archive.com/[email protected]/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.

Quoted 5 lines

Regards

CS

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

Quoted 43 lines

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

Quoted 35 lines

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.

Quoted 34 lines

Quoted 7 lines

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:

Quoted 8 lines

	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

Quoted 2 lines

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.

Quoted 1 line

Thanks for your engagement, Andy!

You're welcome.

Quoted 1 line

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

Thank you.

Regards,
Andy

Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls:

Quoted 113 lines · Chicken Shack

Quoted 100 lines

Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:

Quoted 99 lines · Andy Walls

Quoted 19 lines · Chicken Shack

Quoted 12 lines

Hi,

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

http://www.mail-archive.com/[email protected]/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.

Quoted 5 lines

Regards

CS

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

Quoted 43 lines

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

Quoted 35 lines

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.

Quoted 70 lines

Quoted 34 lines

Quoted 7 lines

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:

Quoted 8 lines

	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

Quoted 2 lines

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.

Quoted 1 line

Thanks for your engagement, Andy!

You're welcome.

Quoted 1 line

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

Quoted 4 lines

Thank you.

Regards,
Andy

Hi Andy,

take care, such golden donations can turn into g**** s***** very soon.

Prefer to stay with the original author.

I think he is still alive ;)

Cheers,
Hermann

Quoted 109 lines

Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls:

Quoted 108 lines · Chicken Shack

Quoted 100 lines

Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:

Quoted 99 lines · Andy Walls

Quoted 19 lines · Chicken Shack

Quoted 12 lines

Hi,

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

http://www.mail-archive.com/[email protected]/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.

Quoted 5 lines

Regards

CS

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

Quoted 43 lines

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

Quoted 35 lines

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.

Quoted 5 lines

Quoted 5 lines

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

Quoted 70 lines

Quoted 70 lines

Quoted 34 lines

Quoted 7 lines

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:

Quoted 8 lines

	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

Quoted 2 lines

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.

Quoted 1 line

Thanks for your engagement, Andy!

You're welcome.

Quoted 1 line

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

Quoted 8 lines

Quoted 4 lines

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

Quoted 4 lines

Prefer to stay with the original author.

I think he is still alive ;)

I've added him to the Cc: list.

Regards,
Andy

Quoted 2 lines

Cheers,
Hermann

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls:

Quoted 48 lines · hermann pitton

Quoted 45 lines

Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls:

Quoted 44 lines · Chicken Shack

Quoted 43 lines

Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:

Quoted 42 lines · Andy Walls

Quoted 19 lines · Chicken Shack

Quoted 12 lines

Hi,

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

http://www.mail-archive.com/[email protected]/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.

Quoted 5 lines

Regards

CS

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

Quoted 16 lines

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

Quoted 8 lines

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

Quoted 49 lines

Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls:

Quoted 48 lines · hermann pitton

Quoted 45 lines

Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls:

Quoted 44 lines · Chicken Shack

Quoted 43 lines

Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:

Quoted 42 lines · Andy Walls

Quoted 19 lines · Chicken Shack

Quoted 12 lines

Hi,

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

http://www.mail-archive.com/[email protected]/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.

Quoted 5 lines

Regards

CS

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

Quoted 16 lines

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

Quoted 8 lines

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/[email protected]/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

Quoted 49 lines

Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls:

Quoted 48 lines · hermann pitton

Quoted 45 lines

Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls:

Quoted 44 lines · Chicken Shack

Quoted 43 lines

Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:

Quoted 42 lines · Andy Walls

Quoted 19 lines · Chicken Shack

Quoted 12 lines

Hi,

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

http://www.mail-archive.com/[email protected]/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.

Quoted 5 lines

Regards

CS

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

Quoted 16 lines

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

Quoted 8 lines

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/[email protected]/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

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.

Quoted 8 lines

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.

Quoted 8 lines

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.

Hi Chicken

Quoted 8 lines

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.

Quoted 8 lines · And as Andy

Quoted 8 lines

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.

Quoted 8 lines

Quoted 8 lines

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.

From what I gather, originally:

Rgds

/Honza

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/[email protected]/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.

Hello Andy,

Quoted 2 lines · Andy Walls

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

Quoted 1 line

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

Quoted 4 lines

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?

Quoted 6 lines

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/[email protected]/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.

Quoted 3 lines

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.

Quoted 3 lines

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?

Quoted 2 lines

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.

Quoted 3 lines

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.

Quoted 5 lines · Andreas Oberritter

Hello Andy,

Quoted 2 lines · Andy Walls

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.

Quoted 1 line

Quoted 1 line

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

Why? Where exactly the breakage happened?

Quoted 31 lines

Quoted 4 lines

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?

Quoted 6 lines

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/[email protected]/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.

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 8 lines

Would this involve running mknod for every recording you start?

Quoted 2 lines

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.

Quoted 4 lines

Quoted 3 lines

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.

Quoted 8 lines

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.

Quoted 5 lines · Andreas Oberritter

Hello Andy,

Quoted 2 lines · Andy Walls

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.

Quoted 1 line

Quoted 1 line

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

Why? Where exactly the breakage happened?

Quoted 31 lines

Quoted 4 lines

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?

Quoted 6 lines

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/[email protected]/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.

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 8 lines

Would this involve running mknod for every recording you start?

Quoted 2 lines

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.

Quoted 4 lines

Quoted 3 lines

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.

Quoted 8 lines

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.

Hello Andy,

Quoted 3 lines · Andy Walls

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

Quoted 5 lines

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?

Quoted 6 lines

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/[email protected]/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.

Quoted 3 lines

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.

Quoted 3 lines

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?

Quoted 2 lines

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.

Quoted 3 lines

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

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.

Quoted 8 lines

Quoted 6 lines

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/[email protected]/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.

Quoted 5 lines

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 6 lines · Andy Walls

Quoted 2 lines

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.

From what I understood, the regression appeared on an old, orphan

Quoted 10 lines · Andreas Oberritter

Quoted 6 lines · Andy Walls

Quoted 2 lines

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.

Quoted 1 line

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

Quoted 6 lines · Andreas Oberritter

Quoted 4 lines · Andy Walls

Quoted 2 lines

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.

Quoted 4 lines

Quoted 2 lines

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.

Quoted 1 line

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.

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

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.

Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab:

Quoted 7 lines

Quoted 6 lines · Andreas Oberritter

Quoted 4 lines · Andy Walls

Quoted 2 lines

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.

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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.

Quoted 2 lines

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!

Quoted 5 lines

Quoted 1 line

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

Quoted 1 line

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.

Quoted 3 lines

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!

Quoted 1 line

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.

Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack:

Quoted 99 lines

Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab:

Quoted 7 lines

Quoted 6 lines · Andreas Oberritter

Quoted 4 lines · Andy Walls

Quoted 2 lines

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.

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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.

Quoted 2 lines

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!

Quoted 5 lines

Quoted 1 line

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

Quoted 1 line

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.

Quoted 3 lines

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!

Quoted 1 line

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.

Quoted 2 lines

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?

Quoted 7 lines

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?

Quoted 4 lines

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.

Am Samstag, den 06.02.2010, 00:12 +0100 schrieb hermann pitton:

Quoted 100 lines

Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack:

Quoted 99 lines

Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab:

Quoted 7 lines

Quoted 6 lines · Andreas Oberritter

Quoted 4 lines · Andy Walls

Quoted 2 lines

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.

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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.

Quoted 2 lines

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!

Quoted 5 lines

Quoted 1 line

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

Quoted 1 line

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.

Quoted 3 lines

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!

Quoted 1 line

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.

Quoted 6 lines

Quoted 2 lines

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?

Quoted 12 lines

Quoted 11 lines

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.

Quoted 2 lines

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?

Quoted 4 lines

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

Am Samstag, den 06.02.2010, 00:39 +0100 schrieb Chicken Shack:

Quoted 108 lines

Am Samstag, den 06.02.2010, 00:12 +0100 schrieb hermann pitton:

Quoted 100 lines

Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack:

Quoted 99 lines

Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab:

Quoted 7 lines

Quoted 6 lines · Andreas Oberritter

Quoted 4 lines · Andy Walls

Quoted 2 lines

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.

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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.

Quoted 2 lines

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!

Quoted 5 lines

Quoted 1 line

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

Quoted 1 line

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.

Quoted 3 lines

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!

Quoted 1 line

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.

Quoted 6 lines

Quoted 2 lines

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?

Quoted 6 lines

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

Quoted 2 lines

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.

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

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.

Quoted 7 lines

Quoted 2 lines

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

Quoted 15 lines

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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?

Am Samstag, den 06.02.2010, 01:25 +0100 schrieb hermann pitton:

Quoted 166 lines

Am Samstag, den 06.02.2010, 00:39 +0100 schrieb Chicken Shack:

Quoted 108 lines

Am Samstag, den 06.02.2010, 00:12 +0100 schrieb hermann pitton:

Quoted 100 lines

Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack:

Quoted 99 lines

Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab:

Quoted 7 lines

Quoted 6 lines · Andreas Oberritter

Quoted 4 lines · Andy Walls

Quoted 2 lines

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.

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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.

Quoted 2 lines

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!

Quoted 5 lines

Quoted 1 line

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

Quoted 1 line

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.

Quoted 3 lines

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!

Quoted 1 line

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.

Quoted 6 lines

Quoted 2 lines

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?

Quoted 6 lines

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

Quoted 2 lines

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.

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

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.

Quoted 7 lines

Quoted 2 lines

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

Quoted 15 lines

Quoted 4 lines

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.

Quoted 8 lines

Quoted 4 lines

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?

Quoted 5 lines

Quoted 3 lines

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

Am Samstag, den 06.02.2010, 09:55 +0100 schrieb Chicken Shack:

Quoted 232 lines

Am Samstag, den 06.02.2010, 01:25 +0100 schrieb hermann pitton:

Quoted 166 lines

Am Samstag, den 06.02.2010, 00:39 +0100 schrieb Chicken Shack:

Quoted 108 lines

Am Samstag, den 06.02.2010, 00:12 +0100 schrieb hermann pitton:

Quoted 100 lines

Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack:

Quoted 99 lines

Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab:

Quoted 7 lines

Quoted 6 lines · Andreas Oberritter

Quoted 4 lines · Andy Walls

Quoted 2 lines

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.

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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.

Quoted 2 lines

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!

Quoted 5 lines

Quoted 1 line

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

Quoted 1 line

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.

Quoted 3 lines

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!

Quoted 1 line

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.

Quoted 6 lines

Quoted 2 lines

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?

Quoted 6 lines

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

Quoted 2 lines

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.

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

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.

Quoted 7 lines

Quoted 2 lines

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

Quoted 15 lines

Quoted 4 lines

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.

Quoted 8 lines

Quoted 4 lines

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?

Quoted 5 lines

Quoted 3 lines

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:

Quoted 8 lines

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

Am Samstag, den 06.02.2010, 09:55 +0100 schrieb Chicken Shack:

Quoted 1 line

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 at least still available for reproducing oopses ;)

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

Cheers,
Hermann

Quoted 11 lines

Am Samstag, den 06.02.2010, 09:55 +0100 schrieb Chicken Shack:

Quoted 1 line

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

Quoted 6 lines

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

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.

Hi Chicken,

Quoted 11 lines

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.

Quoted 5 lines

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.

Cheers

/Honza

Am Sonntag, den 07.02.2010, 19:10 +0100 schrieb HoP:

Quoted 14 lines

Hi Chicken,

Quoted 11 lines

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

Quoted 2 lines

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)

Quoted 6 lines

Quoted 5 lines

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.

Quoted 7 lines

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?

Hi Chicken

2010/2/7 Chicken Shack <[email protected]>:

Quoted 23 lines

Am Sonntag, den 07.02.2010, 19:10 +0100 schrieb HoP:

Quoted 14 lines

Hi Chicken,

Quoted 11 lines

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

Quoted 2 lines

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.

Quoted 9 lines

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.

Quoted 21 lines

Quoted 6 lines

Quoted 5 lines

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.

Quoted 7 lines

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.

Quoted 7 lines

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)

Quoted 5 lines

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.

Quoted 12 lines

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

Quoted 7 lines

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

Quoted 6 lines

Quoted 5 lines

Quoted 1 line

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?

Quoted 6 lines

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

Quoted 2 lines

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'm not even trying to follow this discussion at all, but I feel I have to chime in to be off-topic...

Quoted 13 lines · hermann pitton

Quoted 6 lines

Quoted 5 lines

Quoted 1 line

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?

Quoted 6 lines

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.

Quoted 2 lines

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.

Quoted 5 lines

Quoted 2 lines

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,

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

http://www.mail-archive.com/[email protected]/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 <[email protected]>"

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

Quoted 23 lines · 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/[email protected]/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?

Quoted 7 lines

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 <[email protected]>"

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