Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 208712
Alias:
Product:
Component:
Status: RESOLVED
Resolution: NEEDINFO
Assigned To: Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Bob Raitz <pappy_mcfae@yahoo.com>
Add CC:
CC:
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 208712 depends on: Show dependency tree
Bug 208712 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2008-02-03 10:01 0000
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 From Daniel Drake 2008-02-12 10:45:10 0000 -------
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 From Bob Raitz 2008-02-12 12:08:43 0000 -------
(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 From Bob Raitz 2008-02-14 08:17:31 0000 -------
Pardon my ignorance, but what does the addition of "regression" mean?

Blessed be!
Pappy

------- Comment #4 From Daniel Drake 2008-02-14 09:01:52 0000 -------
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 From Joshua Jackson 2008-04-25 03:11:52 0000 -------
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 From Mike Pagano 2008-08-19 17:36:33 0000 -------
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 From Bob Raitz 2008-09-07 03:16:33 0000 -------
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

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug