kernel panic in oss_audio_open

[srp]

# mdb unix.6 vmcore.6
Loading modules: [ unix krtld genunix specfs dtrace ufs ip sctp usba fctl s1394 nca lofs logindmux ptm fcip sppp random nfs ipc ]
> ::status
debugging crash dump vmcore.6 (64-bit) from unknown
operating system: 5.10 Generic (i86pc)
panic message: mutex_enter: bad mutex, lp=ffffffff8259e7e0 owner=d000d0008 thread=ffffffff83a6f1c0
dump content: all kernel and user pages
> ::stack
vpanic()
mutex_panic+0x6f()
mutex_vector_enter+0x25f()
oss_audio_open+0xbb()
audio_open_vdsp+0x115()
sound_open+0x105()
dev_open+0x19()
spec_open+0x131()
fop_open+0x58()
vn_openat+0xb8()
copen+0x1e5()
open32+0x16()
sys_syscall32+0xd9()
>

Solaris 10 on HP pavilion zv5405 (AMD64). SondMax (ADI) card. Crash happens everytime an audio application is used.

Please help. I can't even switch to JDS from CDE without disabling oss )

[dev]

# mdb unix.6 vmcore.6
Loading modules: [ unix krtld genunix specfs dtrace ufs ip sctp usba fctl s1394 nca lofs logindmux ptm fcip sppp random nfs ipc ]
> ::status
debugging crash dump vmcore.6 (64-bit) from unknown
operating system: 5.10 Generic (i86pc)
panic message: mutex_enter: bad mutex, lp=ffffffff8259e7e0 owner=d000d0008 thread=ffffffff83a6f1c0
dump content: all kernel and user pages
> ::stack
vpanic()
mutex_panic+0x6f()
mutex_vector_enter+0x25f()
oss_audio_open+0xbb()
audio_open_vdsp+0x115()
sound_open+0x105()
dev_open+0x19()
spec_open+0x131()
fop_open+0x58()
vn_openat+0xb8()
copen+0x1e5()
open32+0x16()
sys_syscall32+0xd9()
>

Solaris 10 on HP pavilion zv5405 (AMD64). SondMax (ADI) card. Crash happens everytime an audio application is used.

Please help. I can't even switch to JDS from CDE without disabling oss )

Hi,

If you are setting up OSS to automatically boot then you need to edit /etc/rc3 and comment out the modunload -i 0 line.

The problem is that solaris pulls out the driver module and hence the open causes a panic - we need to figure out a way to prevent the modunload -i 0 from unloading OSS.

One opton is to add sleep 20; $OSSLIBDIR/bin/soundon to the S99oss script (/etc/init.d/oss) and this basically will start OSS 20 seconds after the system finishes all the rc script initialization.



best regards
Dev Mazumdar

[Guest]

commenting out the modunload helped. But does this mean that modules that are not required by system are also loaded now ?

[dev]

commenting out the modunload helped. But does this mean that modules that are not required by system are also loaded now ?

Right, that is the downside but the system will unload them in due time.

The best thing to do is to add the sleep 10 (or 20); before the $OSSLIBDIR/soundon The downside is you'll need to wait that much time after you get the startup screen.

We're looking for a solution.....stay tuned.



regards
Dev

[Guest]

sleep 20 before $OSSLIBDIR/soundon still caused the exact same panic when I did a "cat /dev/audio".

Maybe i need to sleep longer. I am ok with commenting the modunload for now.

Thanks for all the hard work on the oss drivers

[dev]

sleep 20 before $OSSLIBDIR/soundon still caused the exact same panic when I did a "cat /dev/audio".

Maybe i need to sleep longer. I am ok with commenting the modunload for now.

Thanks for all the hard work on the oss drivers

Hi,


We've now implemented a fix in the drivers that prevents OSS from getting unloaded by modunload -i 0. Please run ossupdate (or download the OSS 3.99.2c version again) and install it and remove any changes to /etc/rc3 and also any changes to /etc/init.d/oss (or /etc/rc3.d/S99oss) for the sleep stuff.


We've verified this on our machines and it's working reliably.


best regards
Dev Mazumdar

[srp]

Yep, downloaded and installed OSS 3.99.2 c.

It works just fine. I can see console messages complaining about the oss driver being locked in memory.

Thanks for the fix. This works great

[robert]

Anonymity of a SOCKS Proxy. As SOCKS (as it was already marked above) transfers all data from a client to a server, nothing adding from itself, from the point of view of a web-server, a socks proxy is a client. Therefore anonymity of this type of proxy servers is very high.: http://www.socksproxylist.com