Red Hat Bugzilla – Bug 57564
SoundBlaster Live! card freezes the system
Last modified: 2007-04-18 12:38:44 EDT
Description of Problem: Gnome can't be run for anymore than about an hour.
Can't see any pattern to the grief and I can't prevoke it to do it on cue. It
happens many times with the mouse in mid movement across the screen.
The email@example.com seemed to think the NVIDIA driver might be at
issue. I'm using the XFree86 "nv". The video card is an ASUS V7100(T)
AGP SD-2MX32. The Main board is a SOYO SY-6KB 384 megs ram P2
Version-Release number of selected component (if applicable):
How Reproducible: Every time
Steps to Reproduce:
1. Run Gnome
3. Push the big red button and thank the stars for journalling. <g>
Actual Results: The entire system freezes with no virtual terminals available.
No cntl alt bksp available and no visible activity from mouse or keyboard.
Expected Results: cntl alt bksp to restart xserver or ctrl alt F1 to get to a
teminal for "ps -aux" to identify and kill the rogue process.
Additional Information: I'm certainly not doing anything but guessing when I
aim your efforts at the "gnome-core" The crashes are hard enough to have
the journalling kick me to a manual "fsck" then reboot. Then the journalling
seems to be able to get me back to a gui.
Created attachment 40749 [details]
Created attachment 40750 [details]
As was pointed out several times on gnome-list, if gnome freezes the system it
is an X or kernel bug, or a hardware bug, not a gnome bug.
Can you still reproduce this problem if you remove the SoundBlaster Live! sound
card, or replace it with another sound card make/model?
I believe the problems you are reporting may be related to the SoundBlaster
Live! in your system (in combination with the RHL 7.2 kernels and Esound).
I got the SB live sound card out today and have SB AWE64 in it's place. Have
not got it running yet but I?m not sure that makes any differnence to your
The problems seem to be gone.
I've been up and running Gnome for about eight hours pushing and proding with no
freezing up trouble.
Ok. Changing the component to "kernel".
Changing assignee to default owner of the kernel (If someone disagrees, feel
free to smack my head).
I had this problem as well... It is with the live drivers that are included in
the RedHat kernel. ( I know I had the problem with 2.4.9-13, and am currently
running 2.4.7-10). What I did to fix it was download the CVS emu10k1 drivers
from opensource.creative.com. (now on sf.net/projects/emu10k1) I downloaded tag
v0_17. I had to modify some of the code as the RH's kernel is not quite in sync
with the official kernel.
Now that I installed and loaded the new emu10k1 driver, I haven't had a single
I found that this possibly may be a problem with the stock RH emu10k1 driver and
the Epox 7KXA motherboard I have (Via KX133 chipset) as I have read on
newsgroups and other sites that the people having crashes in RH 7.2 are using
According to the lspci output attached to this report, the original reporter
seems to have a motherboard with Intel chipset. Personally, I have had these
freezes both with Intel BX and Intel i815-based motherboards. I thus doubt Via
chipsets are a common denominator.
In the recently released 2.4.9-21 kernel I added the "CVS" sblive driver in
addition to the stock one. That driver is called emu10k1_new.o, and you can
activate it by editing /etc/modules.conf and adding the _new to the drivername there
I just upgraded my kernel from 2.4.7-10 to 2.4.9-21 and used the emu10k1_new
module.. Works great.. I, however, didn't dare try the emu10k1 module..
I switched to the emu10k1_new module in the middle of last week, and my system
has been very stable under heavy use ever since. (It had been crashing
daily.) The change also corrected a play *.wav sound corruption problem (bug
55795) that I'd been experiencing since the upgrade to kernel 2.4.9-21.
I think we have a winner!
There is one thing I have been noticing ever since upgrading to the 1.4.9-21
kernet and using the emu10k1_new driver..(0_17) is that if esd hasn't been used
for a while (and "disconnects" from the DSP). when a sound does play through
ESD it makes a loud POP..as though the volume was REALLY loud for that sound.. I
have xmms playing directly to the DSP almost all the time and it's not affected..
Any clues?? I didn't have this under 2.4.7-10 using my OWN compilation of the
emu10k1 (0_17). Could this be an ESD issue? or an emu10k1 driver issue?
Changing to the _new module seems to have fixed my stability problems. However,
I am still experiencing the "popping" problem that firstname.lastname@example.org mentions.
And unlike him, I'd seen this problem prior to the 2.4.9-21 kernel; in fact, it
might have been since one of the 7.1 errata kernels...
*** Bug 61190 has been marked as a duplicate of this bug. ***