Solaris 10 (x86, b72) & oss

[foonon]

I wrote an smf(5) service definition (using the S99oss script as the staring point for the start/stop method script).

I found that after the system boots, even though the logs all indicate that 'soundon' executed successfully, any attempt to use /dev/dsp (like, via osstest) results in a system panic. If I run soundon again (by hand, after the system boots) things seem to work just fine. I made certain that the boot-time soundon invocation was as late as possible in the boot cycle. This behavior exhibits itself even when using the legacy S99oss script in /etc/rc3.d

Also, why is /reconfigure created every time I run soundon? I suspect that Solaris is doing this behind the scenes.

Anyway, back to audioens for now (I'm using a sound blaster 16 pci card)

~f

[Guest]

I wrote an smf(5) service definition (using the S99oss script as the staring point for the start/stop method script).

I found that after the system boots, even though the logs all indicate that 'soundon' executed successfully, any attempt to use /dev/dsp (like, via osstest) results in a system panic. If I run soundon again (by hand, after the system boots) things seem to work just fine. I made certain that the boot-time soundon invocation was as late as possible in the boot cycle. This behavior exhibits itself even when using the legacy S99oss script in /etc/rc3.d

Also, why is /reconfigure created every time I run soundon? I suspect that Solaris is doing this behind the scenes.

Anyway, back to audioens for now (I'm using a sound blaster 16 pci card)

~f

Hi,

Edit /etc/rc3 and look for the line modunload -a towards the end of the file. Comment it out and the panic goes away. Something has changed in the way Solaris handles modules and all of this will be fixed up shortly.


regards
Dev

[foonon]

Thanks! I'll give it another go. (Why do they do that?)

Oh, one more thing...is it horribly wrong to make /dev/audio a symlink to /dev/dsp? Am I a bad person if I do that? Or just silly?

~f

[Guest]

Thanks! I'll give it another go. (Why do they do that?)

Oh, one more thing...is it horribly wrong to make /dev/audio a symlink to /dev/dsp? Am I a bad person if I do that? Or just silly?

~f

The link is correct because OSS does "sun devaudio" emulation via the
/dev/dsp -



regards
Dev

[foonon]

Update: I've commented out the "modunload" in /etc/rc3 and now things don't panic, but to get any sound at all I need to run soundon manually anyway.

[rotaecho]

Experiencing the same issue. When I load OSS 399li it panics and locks the machine up.

I can't do the soundon without it panicing as well.

My audio set is: CMedia

Sound Log shows it operating normally, but that's not the case:

more soundon.log
OSS driver loaded OK.
==== devices.cfg ====
# Use soundconf to edit this file.
/SECUREAUDIO OFF
/IRQEXCLUDE 3 4
/DMAEXCLUDE 2

Thanks!

-Puddle

[rotaecho]

I checked for a modunload in the rc3.d script, didn't notice that in my file.

-Puddle

[foonon]

Actually, I ended up going back to the legacy rc3.d/S99oss AND this minor mod to /etc/rc3:

Code: Select all

# diff -c rc3.FCS rc3
*** rc3.FCS     Sun Jan  2 01:15:02 2005
--- rc3 Sun Jan  2 15:49:44 2005
***************
*** 86,90 ****
        # Unload all the loadable modules brought in during boot
        # Delay a few seconds to allow dtlogin to open console first.

!       (sleep 5; modunload -i 0) & >/dev/null 2>&1
  fi
--- 86,90 ----
        # Unload all the loadable modules brought in during boot
        # Delay a few seconds to allow dtlogin to open console first.

!       (sleep 5; modunload -i 0; /etc/init.d/oss start) & >/dev/null 2>&1
  fi


For some reason, starting it twice like this seems to have done the trick for me.

~f