Michael,
As the original author of this driver, I was wondering if you have any ideas
on tracking down the kernel panic that sometimes occurs in this driver when
starting up from cold. Several people have reported similar problems. I have
a ksymoops output which points to the routine fidbirq being called before
the pointer to the grabbing areas has been setup (attached).
Regards
Pete Martin
ksymoops 2.4.5 on i686 2.4.19-16mdk-dvb-t. Options used
-V (default)
-k /proc/ksyms (specified)
-l /proc/modules (default)
-o /lib/modules/2.4.19-16mdk-dvb-t/ (default)
-m /boot/System.map-2.4.19-16mdk-dvb-t (default)
Oops: 0000
CPU: 0
EIP: 0010:[<c8905510>] Tainted: GF
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: c8951c00 ebx: 00000001 ecx: 0095b635 edx: c8951c00
esi: c1c30000 edi: 5aa65fd0 ebp: c0297f2c esp: c0297f1c
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c0297000)
Stack: c1c30000 00000000 c02bc578 fffffff7 c0297f3c c0120164 c1c30000 00000001
c0297f58 c012000a c02bc578 00000046 c02baa60 0000000b c0297f78 c0297f70
c010a416 c32aa7c0 000255b7 c0296000 00000010 c0297fc4 c010c8c8 000255b7
Call Trace: [<c0120164>] [<c012000a>] [<c010a416>] [<c010c8c8>] [<c01071a4>]
[<c0114b35>] [<c0114a80>] [<c0107212>] [<c0105000>]
Code: 80 3f 47 74 08 8d 65 f4 5b 5e 5f 5d c3 51 8d 86 d0 0e 00 00
>>EIP; c8905510 <[msdos].data.end+1c01d/23b6d> <=====
>>eax; c8951c00 <[dvb-ttpci]Root+1f020/3e200>
>>ecx; 0095b635 Before first symbol
>>edx; c8951c00 <[dvb-ttpci]Root+1f020/3e200>
>>esi; c1c30000 <_end+1937428/8509488>
>>edi; 5aa65fd0 Before first symbol
>>ebp; c0297f2c <init_task_union+1f2c/2000>
>>esp; c0297f1c <init_task_union+1f1c/2000>
Trace; c0120164 <tasklet_action+44/70>
Trace; c012000a <do_softirq+aa/b0>
Trace; c010a416 <do_IRQ+b6/c0>
Trace; c010c8c8 <call_do_IRQ+5/d>
Trace; c01071a4 <default_idle+24/30>
Trace; c0114b35 <apm_cpu_idle+b5/150>
Trace; c0114a80 <apm_cpu_idle+0/150>
Trace; c0107212 <cpu_idle+42/60>
Trace; c0105000 <_stext+0/0>
Code; c8905510 <[msdos].data.end+1c01d/23b6d>
00000000 <_EIP>:
Code; c8905510 <[msdos].data.end+1c01d/23b6d> <=====
0: 80 3f 47 cmpb $0x47,(%edi) <=====
Code; c8905513 <[msdos].data.end+1c020/23b6d>
3: 74 08 je d <_EIP+0xd> c890551d
<[msdos].data.end+1c02a/23b6d>
Code; c8905515 <[msdos].data.end+1c022/23b6d>
5: 8d 65 f4 lea 0xfffffff4(%ebp),%esp
Code; c8905518 <[msdos].data.end+1c025/23b6d>
8: 5b pop %ebx
Code; c8905519 <[msdos].data.end+1c026/23b6d>
9: 5e pop %esi
Code; c890551a <[msdos].data.end+1c027/23b6d>
a: 5f pop %edi
Code; c890551b <[msdos].data.end+1c028/23b6d>
b: 5d pop %ebp
Code; c890551c <[msdos].data.end+1c029/23b6d>
c: c3 ret
Code; c890551d <[msdos].data.end+1c02a/23b6d>
d: 51 push %ecx
Code; c890551e <[msdos].data.end+1c02b/23b6d>
e: 8d 86 d0 0e 00 00 lea 0xed0(%esi),%eax
Kernel panic: Aiee, killing interrupt handler!
--------------------------
Looks to me like this is at av7110.c->fidbirq near the end where it
is trying to read from mem[0] while comparing th econtents of mem9[0]
to 0x47.
