oss bug introduced since 2.4.18?

[Paul Forgey]

Since upgrading from 2.4.18 to 2.4.20, I've had a problem unmapping 
mmap'd sound buffers.  This problem is still present in 21-pre3.  
Machine is a P-III Celeron on an Asus CUSL-2 board.

I have a program which captures audio for streaming using mmap 
(verified with ptrace).  When I'm done, I issue a SNDCTL_DSP_SETTRIGGER 
with pointer to int value of 0 and munmap the buffer.  There is about a 
2/3 chance the munmap call will never return and the process will not 
die.  At this point, I can still login to the machine through another 
window or the console, but any process making system calls which I have 
not yet determined follow the same fate as the original problem 
process.  So far, I've found the 'who' and 'ps' commands do this.  The 
ps output runs until what seems to be just before reporting the 
original hung process.

This is not a problem if I boot with .18, but I need to run >= 20 for 
my network card.

I'm using a Sound Blaster Live 5.1, and I've tried switching from the 
supplied drivers in the kernel to using Creative's open source drivers 
with the same results.  So it may be in the core sound and not specific 
to the sound card driver?