On 25 Nov, Artur Poplawski wrote: > Artur Poplawski <[EMAIL PROTECTED]> wrote: > >> Hello, >> >> On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic >> like this:
>> Sleeping on "swread" with the following non-sleepable locks held: >> exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \ >> /usr/src/sys/dev/sound/pcm/dsp.c:146 This enables the panic. >> panic: sleeping thread (pid 583) owns a non-sleepable lock Then the panic happens when another thread tries to grab the mutex. The problem is that the pcm code attempts to hold a mutex across a call to uiomove(), which can sleep if the userland buffer that it is trying to access is paged out. Either the buffer has to be pre-wired before calling getchns(), or the mutex has to be dropped around the call to uiomove(). The amount of memory to be wired should be limited to 'sz' as calculated by chn_read() and chn_write(), which complicates the logic. Dropping the mutex probably has other issues. _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"