Bug 57564 - SoundBlaster Live! card freezes the system
SoundBlaster Live! card freezes the system
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Aaron Brown
:
: 61190 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-12-15 17:02 EST by Ian Timshel
Modified: 2007-04-18 12:38 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-07 19:43:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lspci output (4.78 KB, text/plain)
2001-12-15 17:03 EST, Ian Timshel
no flags Details
XFree86.log (19.85 KB, text/plain)
2001-12-15 17:05 EST, Ian Timshel
no flags Details

  None (edit)
Description Ian Timshel 2001-12-15 17:02:26 EST
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 gnome-list@gnome.org 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 
266 (Kalamath)

Version-Release number of selected component (if applicable):


How Reproducible: Every time


Steps to Reproduce:
1.  Run Gnome
2. Wait 
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.
Comment 1 Ian Timshel 2001-12-15 17:03:47 EST
Created attachment 40749 [details]
lspci output
Comment 2 Ian Timshel 2001-12-15 17:05:00 EST
Created attachment 40750 [details]
XFree86.log
Comment 3 Havoc Pennington 2001-12-15 18:04:38 EST
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.
Comment 4 Christian Rose 2001-12-20 17:48:06 EST
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).
Comment 5 Ian Timshel 2001-12-22 02:54:23 EST
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
tasks.  
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.  
Comment 6 Christian Rose 2001-12-22 10:33:17 EST
Ok. Changing the component to "kernel".
Comment 7 Christian Rose 2001-12-26 20:57:40 EST
Changing assignee to default owner of the kernel (If someone disagrees, feel
free to smack my head).
Comment 8 Edward Rudd 2002-01-26 19:41:33 EST
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
crash..
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
this motherboard.
Comment 9 Christian Rose 2002-01-26 20:39:53 EST
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.
Comment 10 Arjan van de Ven 2002-01-27 05:02:57 EST
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
Comment 11 Edward Rudd 2002-01-27 22:03:46 EST
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..
Comment 12 Need Real Name 2002-02-11 09:20:21 EST
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!
Comment 13 Edward Rudd 2002-02-11 13:36:06 EST
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?
Comment 14 Ed Bailey 2002-02-13 10:57:43 EST
Changing to the _new module seems to have fixed my stability problems.  However,
I am still experiencing the "popping" problem that eddie@omegaware.com 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...
Comment 15 Greg Smith 2002-03-18 11:44:44 EST
*** Bug 61190 has been marked as a duplicate of this bug. ***

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