[Python-Dev] Re: Kernel panic writing to /dev/dsp with cmpci driver

[Greg Ward]

On 24 October 2003, I said:
> I'm going to try backing out that patch to see if the problem
> persists; if so, I'll report back here with more details on the panic.

OK, I tried it with a vanilla 2.4.23-pre8.  The panic is still there,
and now I can reproduce it with my C program.  (However, I had to run it
twice.  I'm guessing that if I had run it twice under the preemptible
kernel, it would have crashed then too.)

So it looks like this is definitely a kernel bug, the Python ossaudiodev
driver is not doing anything too perverse, and RML's preemptible kernel
patch is not to blame.  So here's the ksymoops output:

"""
ksymoops 2.4.9 on i686 2.4.23-pre8-gw2.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.23-pre8-gw2/ (default)
     -m /boot/System.map-2.4.23-pre8-gw2 (specified)

c01124d3
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c01124d3>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010013
eax: 72756f2e   ebx: 40017000   ecx: 00000000   edx: 72756f2e
esi: df52c4ac   edi: 00000003   ebp: dd9add58   esp: dd9add3c
ds: 0018   es: 0018   ss: 0018
Process crasher (pid: 1846, stackpage=dd9ad000)
Stack: 
Call trace:    [<c0108945>] [<c0108ac4>] [<c010b168>] [<c01a38dc>] [<c01a3bbe>] [<c01360b3>] [<c010740f>]
Code: 8b 01 85 c6 75 19 8b 02 89 d3 89 c2 0f 18 00 39 f3 75 ea ff


>>EIP; c01124d3 <__wake_up+33/80>   <=====

>>esi; df52c4ac <_end+1f215128/204fecdc>
>>ebp; dd9add58 <_end+1d6969d4/204fecdc>
>>esp; dd9add3c <_end+1d6969b8/204fecdc>

Trace; c0108945 <handle_IRQ_event+45/70>
Trace; c0108ac4 <do_IRQ+64/a0>
Trace; c010b168 <call_do_IRQ+5/d>
Trace; c01a38dc <SHATransform+ac/150>
Trace; c01a3bbe <extract_entropy+23e/360>
Trace; c01360b3 <sys_read+a3/140>
Trace; c010740f <system_call+33/38>

Code;  c01124d3 <__wake_up+33/80>
00000000 <_EIP>:
Code;  c01124d3 <__wake_up+33/80>   <=====
   0:   8b 01                     mov    (%ecx),%eax   <=====
Code;  c01124d5 <__wake_up+35/80>
   2:   85 c6                     test   %eax,%esi
Code;  c01124d7 <__wake_up+37/80>
   4:   75 19                     jne    1f <_EIP+0x1f>
Code;  c01124d9 <__wake_up+39/80>
   6:   8b 02                     mov    (%edx),%eax
Code;  c01124db <__wake_up+3b/80>
   8:   89 d3                     mov    %edx,%ebx
Code;  c01124dd <__wake_up+3d/80>
   a:   89 c2                     mov    %eax,%edx
Code;  c01124df <__wake_up+3f/80>
   c:   0f 18 00                  prefetchnta (%eax)
Code;  c01124e2 <__wake_up+42/80>
   f:   39 f3                     cmp    %esi,%ebx
Code;  c01124e4 <__wake_up+44/80>
  11:   75 ea                     jne    fffffffd <_EIP+0xfffffffd>
Code;  c01124e6 <__wake_up+46/80>
  13:   ff 00                     incl   (%eax)
"""

(Err, the "-gw2" version number is a red herring -- this really is an
unpatched 2.4.23-pre8, I swear!)

Is that enough info for a real kernel hacker to track this down?  I'm
not very experienced with kernel panics, so I'm not sure if this is all
you need.  Let me know if I can provide more info.

        Greg