When sound modules are loaded during boot (soundcore, sound, nm256), then
subsequently removed after X is started and GNOME/E is running, the system
*stops* -- reset button, <CTL><ALT><DEL>, etc., do not work and system
must be power cycled.
I wrote an init script to load/unload stat modules, and this is what loads
saound during startup. Modules were unloaded in reverse order to effect
system hang. The init script can be provided if required (but it's my
first so it's awfully primitive).
Created attachment 117 [details]
sound module loaded at boot-time
Hmm... is esd running when you do this? Probably
not, since you wouldn't be allowed to remove it if it was in use.
This is probably related to the fact that the sound is actually
implemented *on* the video chip, and uses part of the video RAM
as it's bufffers.b
If the reset button doesn't work, I guess its too much to hope that
the sysrq keys work if you've enabled them via /proc/sys/kernel/sysrq ?
If they don't (and I fear they won't), then we're looking at some
serious hardware lockup problems rather than just a nice software
error in the driver. Further debugging this requires more knowledge
of the hardware than we have, and I haven't heard from the anonymous
author of this particular driver in ages.
Is anything interesting in the kernel logs after the sound module
is loaded? (/bin/dmesg)
does the 'Used by' field represent the number of apps that have
You might try messing about with the APM/plug n' play settings
in your BIOS. Depending on the vendor, these can sometimes affect
very odd things that the sound chip might be confusing.
I fear we're just going to have to put big "Well, Don't Do That" signs
around certain sound/X operations on the nm256.
It looks like this can actually be closed.
Under 6.1, I had to manually load the modules for the nm256, hence my primitive
init script, which didn't use the switches for module auto-load/unload.
It appears that under the 'Piglet' beta, sound module loading for the nm256 is