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