Re: dsp device busy (me too) vchans weirdness
John Hay [EMAIL PROTECTED] wrote: On Wed, Feb 12, 2003 at 08:31:11PM +0200, John Hay wrote: Just switching vchans off on the Dell made the sound work again. Looks like I have to take that back. I just tried a brand new -CURRENT kernel and vchans are now working. I have only tried it by setting hw.snd.maxautovchans. It does produce a lot of could sleep with messages though: Yeah. I found and fixed that a few days ago. It's been around for at least a month, but for some reason I'm getting a lot of ENODEV errors in dsp_reset() which is what made it known. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
dsp device busy (me too) vchans weirdness
I remember a couple of posts about this problem; but don't recall (and am unable to find in the archives) if there was ever any resolution. Anyway, this just started on a RELENG_5_0 box this morning -- been working fine up until now. I noticed that /dev/dsp wasn't being cloned, so I went about trying individual devices... $ esd -d /dev/dsp0.1 - using device /dev/dsp0.1 /dev/dsp0.1: Device busy $ esd -d /dev/dsp0.2 - using device /dev/dsp0.2 /dev/dsp0.2: Device busy $ fstat /dev/dsp0.0 $ fstat /dev/dsp0.1 $ fstat /dev/dsp0.2 $ cat /dev/dsp0.3 cat: /dev/dsp0.3: Device busy etc... I've double checked and there is NOTHING running that's touching any of the sound devices (which the fstat confirms). Oddly enough, when I was randomly 'cat'-ing sound devices, one of them returned Operation not supported by device. It only did this once, and then went back to Device busy every time after that. $ dmesg | grep pcm pcm0: Intel 82801BA (ICH2) port 0xcc40-0xcc7f,0xc800-0xc8ff irq 10 at device 31.5 on pci0 pcm0: measured ac97 link rate at 55934 Hz $ cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: Intel 82801BA (ICH2) at io 0xc800, 0xcc40 irq 10 bufsz 16384 (1p/1r/4v channels duplex default) $ sysctl hw.snd hw.snd.targetirqrate: 32 hw.snd.report_soft_formats: 1 hw.snd.verbose: 1 hw.snd.unit: 0 hw.snd.maxautovchans: 0 hw.snd.pcm0.buffersize: 16384 hw.snd.pcm0.vchans: 4 hw.snd.pcm0.ac97rate: 55934 I'm not using maxautovchans because that seems to cause random reboots on this hardware (happens with two Dell towers, both with the ICH2 chip). Even weirder still, during the course of writing this mail, dsp0.[1-4] have spontaneously started working again. 0.0 still reports device busy, though that may be normal since the vchans are active. I was going to try changing the number of vchans to see if it had any effect, but since it's working for now I'll try that next time it happens. Craig To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dsp device busy (me too) vchans weirdness
On Wed, Feb 12, 2003 at 08:46:09AM -0600, Craig Boston wrote: I remember a couple of posts about this problem; but don't recall (and am unable to find in the archives) if there was ever any resolution. I have experienced the same thing. I have tried vchan sound on three -current boxes and it works on all but the Dell. The Dell also have the ICH2 sound while the other two have different sound chips. Maybe it has something to do with the ICH driver or else I was just lucky with the other machines. On the Dell have tried setting vchans directly and maxautovchans, but neither did work for me. I did see this on the console though: ## lock order reversal 1st 0xc87d5b00 pcm0:virtual:0 (pcm channel) @ /usr/src/sys/dev/sound/pcm/sound.c:191 2nd 0xc5d99a80 pcm0 (sound cdev) @ /usr/src/sys/dev/sound/pcm/sound.c:163 ## Just switching vchans off on the Dell made the sound work again. Anyway, this just started on a RELENG_5_0 box this morning -- been working fine up until now. I noticed that /dev/dsp wasn't being cloned, so I went about trying individual devices... $ esd -d /dev/dsp0.1 - using device /dev/dsp0.1 /dev/dsp0.1: Device busy $ esd -d /dev/dsp0.2 - using device /dev/dsp0.2 /dev/dsp0.2: Device busy $ fstat /dev/dsp0.0 $ fstat /dev/dsp0.1 $ fstat /dev/dsp0.2 $ cat /dev/dsp0.3 cat: /dev/dsp0.3: Device busy etc... I've double checked and there is NOTHING running that's touching any of the sound devices (which the fstat confirms). Oddly enough, when I was randomly 'cat'-ing sound devices, one of them returned Operation not supported by device. It only did this once, and then went back to Device busy every time after that. $ dmesg | grep pcm pcm0: Intel 82801BA (ICH2) port 0xcc40-0xcc7f,0xc800-0xc8ff irq 10 at device 31.5 on pci0 pcm0: measured ac97 link rate at 55934 Hz $ cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: Intel 82801BA (ICH2) at io 0xc800, 0xcc40 irq 10 bufsz 16384 (1p/1r/4v channels duplex default) $ sysctl hw.snd hw.snd.targetirqrate: 32 hw.snd.report_soft_formats: 1 hw.snd.verbose: 1 hw.snd.unit: 0 hw.snd.maxautovchans: 0 hw.snd.pcm0.buffersize: 16384 hw.snd.pcm0.vchans: 4 hw.snd.pcm0.ac97rate: 55934 I'm not using maxautovchans because that seems to cause random reboots on this hardware (happens with two Dell towers, both with the ICH2 chip). Even weirder still, during the course of writing this mail, dsp0.[1-4] have spontaneously started working again. 0.0 still reports device busy, though that may be normal since the vchans are active. I was going to try changing the number of vchans to see if it had any effect, but since it's working for now I'll try that next time it happens. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dsp device busy (me too) vchans weirdness
On Wed, Feb 12, 2003 at 08:31:11PM +0200, John Hay wrote: On Wed, Feb 12, 2003 at 08:46:09AM -0600, Craig Boston wrote: I remember a couple of posts about this problem; but don't recall (and am unable to find in the archives) if there was ever any resolution. I have experienced the same thing. I have tried vchan sound on three -current boxes and it works on all but the Dell. The Dell also have the ICH2 sound while the other two have different sound chips. Maybe it has something to do with the ICH driver or else I was just lucky with the other machines. On the Dell have tried setting vchans directly and maxautovchans, but neither did work for me. I did see this on the console though: ## lock order reversal 1st 0xc87d5b00 pcm0:virtual:0 (pcm channel) @ /usr/src/sys/dev/sound/pcm/sound.c:191 2nd 0xc5d99a80 pcm0 (sound cdev) @ /usr/src/sys/dev/sound/pcm/sound.c:163 ## Just switching vchans off on the Dell made the sound work again. Looks like I have to take that back. I just tried a brand new -CURRENT kernel and vchans are now working. I have only tried it by setting hw.snd.maxautovchans. It does produce a lot of could sleep with messages though: ## ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:163 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:163 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:163 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:378 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:378 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:378 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:378 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:378 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:434 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:434 ../../../vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:434 ### John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
