Created attachment 409575 [details] alsa-info output from system where audio loops and crashes desktop. kernel 2.6.18-194.el5 Description of problem: Begining with kernel 2.6.18-194.el5 sound doesn't work properly on the DELL Optiplex 740 workstation. Other hardware we own does not appear to be affected. I believe the Audio hardware is a "NVidia MCP51 High Definition Audio" from what I can tell from the system-config-soundcard application. Version-Release number of selected component (if applicable): kernel-2.6.18-194.el5PAE How reproducible: Install box with NVidia MCP51 High Definition Audio with 32 bit RHEL 5 and kernel 2.6.18-194.el5PAE. We are seeing this behavior on the DELL Optiplex 740 with the newest BIOS version. (2.2.4) Enable audio in a user's preferences: run gnome-sound-properties and click on the "Sounds" tab. Check "Enable software sound mixing (ESD)" and also check "Play systems sounds" disable the "Log in" sound effect. If you don't do this the desktop will crash as its playing the login sound and nautilus and the GNOME panel will never load in your session. Click "Close" When launching apps from the panel, instead of making a single "Launch" sound (a single "beep" if you will, it beeps like 15 times in a row. It sounds like its looping. Playing back longer sounds like the "Login sound" or the Error message "Siren" sound causes the GNOME desktop to crash. Buttons and the window manager become un-responsive. Also when this happens the sound doesn't stop playing until you reboot. Driver is snd-hda-intel in /etc/modprobe.conf Steps to Reproduce: 1.install 32 bit RHEL 5 on hardware with NVidia MCP51 High Definition Audio. We are seeing this on the DELL Optiplex 740 workstation. 2. upgrade kernel to 2.6.18-194.el5PAE. 3. enable systems sound effects. Log in and start some apps via the GNOME panel. Listen for system sound effects. Actual results: Gnome sound effects "loop" and sometimes (when long?) crash the desktop. Expected results: Should play sound effects normally like kernel 2.6.18-164.15.1.el5 did. Additional info:
Created attachment 409576 [details] alsa-info output from system where audio works normally. kernel 2.6.18-164.15.1.el5
This may not be strictly a sound bug. The sound problems happen consitantly, even when I build my own kernel from the source rpms. However there is another problem that happens sometimes. About on every fourth reboot the console crashes before rhgb starts. When this happens random text appears on the console. It also has random colors and sometimes some of it blinks. When this happens the only recourse is to power cycle. This happens with 2.6.18-194.el5. It doesn't happen with kernel 2.6.18-164.15.1.el5 at all.
Greetings, This is still a problem in 2.6.18-194.3.1.el5. Also, I discovered that a 64 bit kernel has the same issues that the 32 bit install did. Also, in 2.6.18-194.3.1.el5 I noticed that some mouse movements were extremely sluggish as I logged in. The login took a lot longer than normal. Also, I still hear the weird looping sound effects. So I guess this problem is getting worse. I did a test install of RHEL 6 on the same hardware and it doesn't have the same issues. (2.6.32-19.el6.x86_64) So its limited to RHEL 5.5 kernels. Please let us know if there is anything we can do to help speed up any possible fix. Are there test commands we can run for instance? We have about a hundred of these machines at NCSU that we are holding off upgrading due to this bug. Thanks,
Created attachment 412852 [details] dmesg output from booting kernel 2.6.18-194.3.1.el5 on a DELL Optiplex 740 I thought the output from dmesg might help to track down the issue.
Created attachment 412853 [details] dmesg output from booting kernel 2.6.18-164.11.1.el5PAE on a DELL Optiplex 740 This is the output from dmesg on a machine that hasn't had its kernel upgraded so its working properly. Same make /model, DELL Optiplex 740.
We have discovered that turning off audio in the BIOS seems to remove the problems with mouse lag and crashing at boot up. Of course there is no sound with audio disabled. When re-enabling audio in the BIOS the looping, the crashing, and the mouse lag come back.
I believe this is the same issue we've started seeing on Optiplex 740s. We're doing more testing.
So at a glance through the changelog, I'd have to put a wager on "[sound] alsa hda driver update for rhel5.5 (Jaroslav Kysela) [525390]" being the culprit here. The first order of business is probably to verify that, by taking a RHEL5.5 kernel, reverting (or simply not applying) that update patch, and trying it out. If that works, then we can work on chasing the specific part of the patch that caused the problem. If not... Well, we'll come up with a new idea, but I'm reasonably sure its going to be something in that patch. John, can you provide a test kernel? I can probably whip one up if you'd prefer. Alternatively, Gary and Jason, if you're comfortable with rebuilding a kernel from an installed srpm's spec file, simply commenting out the application of patch24883 and doing an rpmbuild -bp kernel-2.6.spec should result in a testable kernel build.
I've started building the test kernel with that patch removed. I will test whenever it finishes.
Happy to report that removing patch 24883 produced a test 5.5 kernel with none of the weird sound effects or slowness. So I agree the problem lives inside that patch somewhere. I rebuilt kernel 2.6.18-194.el5 if it matters.
Okay, adding Jaroslav to the bug cc list, as he's the author of the patch that is verified to be the cause of this regression, and marking this bug as a regression. I haven't the alsa expertise to further track this down myself, but hopefully, Jaroslav (and/or John) has some ideas here, now that the responsible patch has been identified.
And btw, Gary, thank you for the legwork, much appreciated. :)
Could you try to test on problematic machine the 'enable_msi=0' module option for snd-hda-intel kernel module?
The commit in upstream regarding msi is here: http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=80c43ed724797627d8f86855248c497a6161a214
changing /etc/modprobe.conf from options snd-hda-intel index=0 to options snd-hda-intel index=0 enable_msi=0 on the latest stock kernel, 2.6.18-194.3.1.el5 seems to also fix the issue.
I was hit by this bug. When the kernel was updated to -194, I started having problems with not just the sound but system sluggishness and crashes. Adding enable_msi=0 fixed the problem. My hardware: 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
Same problem on Dell Optiplex 740 (but running CentOS).
This is still a problem with the newest Red Hat kernel, 2.6.18-194.8.1.el5. The workaround, changing the line options snd-hda-intel index=0 to options snd-hda-intel index=0 enable_msi=0 within /etc/modprobe.conf is still working. We are still using this workaround until the patch gets applied to the newest kernel.
This bug is relevant for a DELL Optiplex 745 hardware as well (Scientific Linux 5, kernel 2.6.18-194.11.1.el5). The workaround (comment 17) solves the problem. I had to reboot the PC for the change to become active. It became then active for the front panel output (name "Headphone"), for the rear output (labeled "Front"!), I had to disable/unable the channel once in gnome-volume-control to have the same effect.
(In reply to comment #26) > for the rear output (labeled "Front"!), I had to disable/unable > the channel once in gnome-volume-control to have the same effect. Read: "I had to disable/Enable ..." :-}
Created attachment 446965 [details] This patch fixes the sound issues with NVidia sound chip recently introduced I have posted kernels built with this patch added at: http://install.linux.ncsu.edu/pub/yum/itecs/public/testkernel/ Please test on Optiplex 740 and 745 machines affected by bug. I have found that this kernel does fix the sound/slow mouse/crashing issues. Let me know if you need any other info on this. I tested this kernel with the front headphone jack and sound worked perfectly. :)
Just wanted to add when I built these kernels I added the patch to the spec file as Patch25159. I think it should work anywhere after Patch24883.
This patch is in redhat kernel available for bug#592199 (use kernel-2.6.18-215.el5).
*** This bug has been marked as a duplicate of bug 592199 ***
(In reply to comment #31) > > *** This bug has been marked as a duplicate of bug 592199 *** It may well be but, unfortunately, the way this bz system is configured when a normal mortal person goes to bug 592199 {she|he} will see: You are not authorized to access bug #592199. In the utterance of Homer (Simpson): "D'oh!"
Just grab the latest published test kernel from http://people.redhat.com/~jwilson/el5/
During the last hours I have tested http://people.redhat.com/~jwilson/el5/223.el5/x86_64/kernel-2.6.18-223.el5.x86_64.rpm. Unfortunately although the system is not sluggish as with stock -194 kernels, there is no sound at all. Hardware under test: ASUS M2NBP-VM CSM ACPI BIOS Revision 1001. Full specs / more testing available on details.
> Hardware under test: ASUS M2NBP-VM CSM ACPI BIOS Revision 1001. Full specs / > more testing available on details. To be read : testing available on request
Just tested 2.6.18-233 again on another ( identical ) system. Same problem, there is no sound at all.
(In reply to comment #36) > Just tested 2.6.18-233 again on another ( identical ) system. Same problem, > there is no sound at all. On that same system, would the workaround ( enable_msi=0 ) work?
On the first system, 2.6.18-194.4.11 + workaround is OK. Without it the system is sluggish, keyboard key presses are recorded several times even when pressed only once, adobe's flash player locks the sound driver and never ends. On the second one, the above combination worked exactly once , until reboot. After the following reboots (!) there was no sound at all, independent if the workaround is applied or not. For what is worth,kernel-2.6.18-164.15.1.el5.x86_64.rpm does NOT work either ( at least not _without_ the workaround; I have not tested _with_ the workaround ) On the other hand, 2.6.18-92.1.6.el5 worked always ( and is online right now ). Since both computers mentioned above are in production, testing is a bit problematic ( especially as I will be on vacation the next week). However I have a third identical box which I could use for any tests imaginable, as it's not used at all for the moment. I'm attaching the output of lspci and dmidecode, maybe those help in identifying the hardware with issues.
Created attachment 449433 [details] output of lspci
Created attachment 449434 [details] output of dmidecode; includes motherboard and bios revision
Try to compare alsa-info.sh output for working and non-working setup.
Created attachment 451150 [details] output from alsa-info.sh run on a functional kernel I am attaching the output of alsa-info.sh for a functional and a non functional kernel. maybe someone more knowledgeable than me can use them to spot a problem. The "options snd-hda-intel index=0 enable-msi=0" line which is present in the modprobe.conf file is not needed with this kernel. it is a leftover from the other tests.
Created attachment 451151 [details] this is the output for an experimental, non-functional ( even with the disable msi workaround applied ) kernel
Ok, CentOS user, try to use different 'model=' parameter for your hw for snd-hda-intel hw. It seems that in newer ALSA driver the laptop model is selected for your hw which is not probably right. Anyway, the bug is not related with the original MSI issue (system crash).
Because bug #592199 is not publicly accessible, would someone from Red Hat let us know if the patch will be in RHEL 5.6?
(In reply to comment #45) > Because bug #592199 is not publicly accessible, would someone from Red Hat let > us know if the patch will be in RHEL 5.6? Yes, it will.