Craig Dooley wrote: >I have the same problem. heres my debug dump. It seems to happen to me >always when sound is playing. I also get pages of warnings about pcm >and could sleep with lock. > >/usr/src/sys/vm/uma_core.c:1332: could sleep with "pcm0:play:0" locked from >/usr/src/sys/dev/sound/pcm/dsp.c:690 >/usr/src/sys/vm/uma_core.c:1332: could sleep with "pcm0:play:0" locked from >/usr/src/sys/dev/sound/pcm/dsp.c:713 >/usr/src/sys/vm/uma_core.c:1332: could sleep with "pcm0:play:0" locked from >/usr/src/sys/dev/sound/pcm/sound.c:191 >and so on. actually it's flooded dmesg enough that I cant get to any >useful information without going back a couple message.x's. buildworld >and kernel built from yesterdays sources. > I've been looking into trying to fix the pcm code and it seems to be riddled with places where locks are held while sleepable memory allocations (the umacore.c:1332) are attempted. I mostly run without sound for now until I can get a grasp on where I can get away with not locking. Some locks are created and immediately locked, which to me only makes sense if the struct in which the lock exists is entered into a list where it's processed by some other KSE (I hope I'm not mangling these terms, I've only done Linux kernel work to-date). Is the pcm code maintainer looking into this also?
>> >> -- Anthony Jenkins http://www.mindspring.com/~abjenkins/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
