Kernel panic writing to /dev/dsp with cmpci driver

Kernel panic writing to /dev/dsp with cmpci driver

[Greg Ward]

[cc'ing python-dev because there might be something funny in the
ossaudiodev module -- but some of you already know that!]

I've just upgraded to Linux 2.4.23-pre8 + RML's preemptible kernel
patch, and I have a pretty reproducible panic when writing to /dev/dsp.
Here's what lspci reports about the sound hardware:

02:03.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)

I'm using the cmpci driver.  Oddly, the panic only happens when using
Python 2.3's ossaudiodev module, which is a fairly thin wrapper around
the OSS API.  Here's a script that crashes my machine every time:

"""
#!/usr/bin/python2.3

import sys
import ossaudiodev

random = open("/dev/urandom", "r")
dsp = ossaudiodev.open("w")
while 1:
    sys.stdout.write("."); sys.stdout.flush()
    dsp.write(random.read(4096))
"""

(I'm quite sure that the panic has nothing to do with /dev/urandom,
since I discovered the it by playing Ogg Vorbis files, not by playing
white noise.)  The crash happens after about 10-12 dots have appeared,
ie. 10-12 4k blocks have been written.

Here's a C version of that script that does *not* crash my system:

"""
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/soundcard.h>

#define BUF_SIZE 4096

int main(int argc, char ** argv)
{
   int nbytes;
   char data[BUF_SIZE];
   int source, dsp;		       /* input, output FDs */

   source = open("/dev/urandom", O_RDONLY);
   dsp = open("/dev/dsp", O_WRONLY);
   printf("source fd=%d, dsp fd=%d\n", source, dsp);
   
   while (1) {
      printf("."); fflush(stdout);
      nbytes = read(source, data, BUF_SIZE);
      write(dsp, data, nbytes);
   }
}
"""

Just wondering if anyone else has seen something like this in
2.4.23-pre8, either with or without the preemptible kernel patch.  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.

Oh yeah, this is a Red Hat 9 system -- the sound driver worked perfectly
with Red Hat's 2.4.20-20.9 kernel (which, from the source RPM, appears
to be 2.4.21-pre3 plus a bunch of Red Hat patches).

        Greg

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›9ad000)
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
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html