Bug 9436 - system hangs when sound modules removed in GNOME
Summary: system hangs when sound modules removed in GNOME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 6.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-02-14 19:03 UTC by scott.reimert
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-02-15 20:05:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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 19:09 UTC, scott.reimert
no flags Details

Description scott.reimert 2000-02-14 19:03:58 UTC
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 19:09:59 UTC
Created attachment 117 [details]
sound module loaded at boot-time

Comment 2 Bill Nottingham 2000-02-15 03:13:59 UTC
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 14:48:59 UTC
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 20:05:59 UTC
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.