On 17 Jan, Stefan Ehmann wrote: > On Sat, 2004-01-17 at 10:15, Don Lewis wrote: >> I think this problem can be caused by a transient malloc() M_NOWAIT >> failure. >> >> Changes in this version of the patch: >> >> When increasing blksz in chn_setblocksize(), increase the size >> of bufsoft before increasing bufhard, and decrease bufsoft after >> decreasing bufhard in an attempt to avoid the buffer overflow in >> feed_vchan_s16(). >> >> Buffers are now allocated using M_WAITOK, requiring locks to >> be dropped for the malloc() calls. This required adding a mutex >> parameter to sndbuf_remalloc(). >> >> Locking order between parent and child channels is changed. The >> parent is now locked first and then the child. The list of >> children is protected by the parent's lock. There are still >> potential race conditions in the vchan creation/destruction code >> because all the locks have to be dropped in order to call >> malloc(), etc. >> >> Locking cleaned up to eliminate the need for MTX_RECURSE. >> >> A new mutex allocator for the channel mutexes was added that >> initializes the mutexes with the MTX_DUPOK flags so that multiple >> channel mutexes of the same type can be held at once. >> >> Locking simplification in dsp_ioctl(). >> >> Added KASSERTs in chn_wrfeed(). > > Some more observations: > > - I haven't run the patched kernel long enough to see if it actually > prevents panics. > > - Sometimes when trying to open dsp it fails at the first attempt, but > works if I try again. I had similar experiences when I first used vchans > but these problems have been gone for long. I haven't seen this ... > - This also seems to lock up one of the vchans each time this happens (I > haven't really tested this yet but I'm pretty sure). For instance, if I > try to set the number of vchans to anything lower than 3 right now it > fails saying device busy. My guess would be that those vchans were > locked but never unlocked for some reason. or this. > - If I use esd as output device (e.g. for ogg123 because it doesn't work > properly with the default output) an I stop the player, it takes some > seconds before the sound actually stops playing (until the buffer is > written to dsp). This doesn't happen with unpatched pcm module. I have seen this. I've been testing with wavplay and when I ^c the player it can take quite a while before the sound stops playing and the player exits. I think it is sitting in chn_flush(), but I haven't looked closely at it.Received on Sat Jan 17 2004 - 11:54:27 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:38 UTC