Bug 9436 - system hangs when sound modules removed in GNOME
system hangs when sound modules removed in GNOME
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-02-14 14:03 EST by scott.reimert
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-15 15:05:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sound module loaded at boot-time (786 bytes, text/plain)
2000-02-14 14:09 EST, scott.reimert
no flags Details

  None (edit)
Description scott.reimert 2000-02-14 14:03:58 EST
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).
Comment 1 scott.reimert 2000-02-14 14:09:59 EST
Created attachment 117 [details]
sound module loaded at boot-time
Comment 2 Bill Nottingham 2000-02-14 22:13:59 EST
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
Comment 3 Zach Brown 2000-02-15 09:48:59 EST
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.

Some thoughts:

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
/dev/dsp open?

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.
Comment 4 scott.reimert 2000-02-15 15:05:59 EST
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
done automatically.

Note You need to log in before you can comment on or make changes to this bug.