Kernel panic writing to /dev/dsp with cmpci driver

[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

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

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html