Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 208712 - [2.6.24 regression] intel-hda not usable after reboot to older kernel
Summary: [2.6.24 regression] intel-hda not usable after reboot to older kernel
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
URL:
Whiteboard: linux-2.6.24-regression
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-03 10:01 UTC by Bob Raitz
Modified: 2008-09-07 03:16 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bob Raitz 2008-02-03 10:01:17 UTC
The 2.6.24 version of the Linux kernel (vanilla or gentoo flavors) take control of the sound system, and will not release control of the sound system to earlier kernel versions. 

Reproducible: Always

Steps to Reproduce:
1. on a multi-boot system, boot the 2.6.24 version kernel.
2. soft boot to another earlier kernel version (2.6.22.16 in my case), and no sound is heard.

Actual Results:  
As long as you continue to soft reboot, there will be no sound heard. A hard reboot (halt followed by powering the system back up again) will reset the sound card, and it will function under the older kernel versions.

Expected Results:  
The expected result was that the alsa drivers in the 2.6.24 kernel would release the sound system and allow it to function. That doesn't happen.

This bug was found by accident while trying to get wireless networking functional. The only visible complaint occurs when loading the alsa modules at boot time. If the kernel is switched from new to old or old to new, the initial boot under that kernel will give indication of problems. Each subsequent reboot with the same kernel yields no boot time output.
Comment 1 Daniel Drake (RETIRED) gentoo-dev 2008-02-12 10:45:10 UTC
Which was the last known working kernel that didn't have this bug?

Please elaborate on "give indication of problems"

Also, on the older kernels, when you say "no sound is heard", do the sound apps *appear* to be functioning as usual? Or do they simply hang when you try and play a sound?
Comment 2 Bob Raitz 2008-02-12 12:08:43 UTC
(In reply to comment #1)
> Which was the last known working kernel that didn't have this bug?
> 
That depends on your definition of working. It appeared to work well with 2.6.23.4 (vanilla), and definitely works well with 2.6.22.15, 16, and 17. However, when switching to 2.6.24, and using the multi-chip setup for the intel hda, the problem arose

> Please elaborate on "give indication of problems"
> 
By that, I mean there is no indication given when starting KDE that there is a problem. The same thing happens when I boot directly from Windows to Gentoo without powering the system down. The Gentoo boot process is normal. No indication of module problems. Starting KDE doesn't bring up an error...however, the sound refuses to work again until the unit is powered down, and booted with the older version kernels.

> Also, on the older kernels, when you say "no sound is heard", do the sound apps
> *appear* to be functioning as usual? Or do they simply hang when you try and
> play a sound?
> 
I have audacity, audacious, gxine, mplayer, noatun, and a few other audio programs installed. Gxine indicates that it is "playing" by either moving the shuttle button in the case of an mp3, or by the timer ticking while receiving an internet broadcast. The starting and ending KDE sounds don't sound (the first indication of trouble). All the other programs look like they are doing something, but there isn't a peep from the speakers. 

This only seems to happen with the intel-hda. I have another system with a Midi-man six channel pro card that sure seems to work when swapping between kernel versions. I haven't compiled the 2.6.24 kernel on my Toshiba Laptop, but I get the feeling it wouldn't notice either, since it can boot between Windows and Gentoo all day, and the sound works fine no matter which OS is running. It uses an AC97.

Might I suggest that if the kernel is going to put up so many different chipsets for consideration, perhaps there might be some indication made by the kernel as to which modules are loading, and which aren't. That way, you can choose exactly the right chipset. This could avoid a possible conflict, and the kernel size would be reduced. Could the multiple chipset settings be the problem?

Thanks for your time and consideration.

Blessed be!
Pappy
Comment 3 Bob Raitz 2008-02-14 08:17:31 UTC
Pardon my ignorance, but what does the addition of "regression" mean?

Blessed be!
Pappy
Comment 4 Daniel Drake (RETIRED) gentoo-dev 2008-02-14 09:01:52 UTC
It means that this is a bug that was added, rather than one that has always existed. Regressions are the most serious form of bugs.
Comment 5 Joshua Jackson (RETIRED) gentoo-dev 2008-04-25 03:11:52 UTC
DSD,

I can give you some decent info about the issue and there appears to be bugs over at ubuntu for it as well.

According to their wiki there's some potential fixes
https://wiki.ubuntu.com/Gutsy_Intel_HD_Audio_Controller

cat /proc/asound/cards:
 0 [Intel          ]: HDA-Intel - HDA Intel
                      HDA Intel at 0xfebfc000 irq 21

cat /proc/asound/card0/codec#0
Codec: SigmaTel STAC9205
Address: 0
Vendor Id: 0x838476a0
Subsystem Id: 0x102801f9
Revision Id: 0x100204

cat /proc/asound/pcm     
00-01: STAC92xx Digital : STAC92xx Digital : playback 1
00-00: STAC92xx Analog : STAC92xx Analog : playback 1 : capture 2

So its seen by the kernel at least as a viable device. Alsamixer and Alsaconf both see the card and report it as such and can be configured by alsaconf.

When attempting to play anything via any sound required device you'll get:

[AO_ALSA] alsa-lib: confmisc.c:769:(parse_card) cannot find card ''
[AO_ALSA] alsa-lib: conf.c:3510:(_snd_config_evaluate) function snd_func_card_driver returned error: No such device
[AO_ALSA] alsa-lib: confmisc.c:392:(snd_func_concat) error evaluating strings
[AO_ALSA] alsa-lib: conf.c:3510:(_snd_config_evaluate) function snd_func_concat returned error: No such device
[AO_ALSA] alsa-lib: confmisc.c:1251:(snd_func_refer) error evaluating name
[AO_ALSA] alsa-lib: conf.c:3510:(_snd_config_evaluate) function snd_func_refer returned error: No such device
[AO_ALSA] alsa-lib: conf.c:3982:(snd_config_expand) Evaluate error: No such device


Comment 6 Mike Pagano gentoo-dev 2008-08-19 17:36:33 UTC
What the status of this issue with later kernels?

Was 2.6.25 tried, 2.6.26 or a dev kernel (git-sources)?
Comment 7 Bob Raitz 2008-09-07 03:16:33 UTC
At this point, as far as I'm concerned, the bug is a non-issue. While I haven't tested this bug in some time, I hardly ever start Windows anymore, and there were other problems that kept me from doing anything with the .24 kernel family after 2.6.24-gentoo-r2 before I gave up and waited for 2.6.25 while still using 2.6.22.19 and 2.6.22-gentoo-r10. 

So, as far as I'm concerned, this bug can be called fixed via attrition or update...however you folks categorize something of this nature.

Blessed be!
Pappy