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 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.
Created attachment 40749 [details] lspci output
Created attachment 40750 [details] XFree86.log
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 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.
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 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.
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 eddie 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. ***