Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 274196

Summary: sys-kernel/gentoo-sources-2.6.30-r1: emu10k1 lost mixer settings
Product: Gentoo Linux Reporter: Martin von Gagern <Martin.vGagern>
Component: [OLD] Core systemAssignee: Gentoo Linux bug wranglers <bug-wranglers>
Status: RESOLVED CANTFIX    
Severity: normal CC: heltem+gentoo
Priority: High Keywords: REGRESSION
Version: 2008.0   
Hardware: x86   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Martin von Gagern 2009-06-15 07:06:14 UTC
After compiling and booting the 2.6.30-gentoo-r1 kernel, my sound card didn't produce any sound using the emu10k1 driver. Modueles were loaded and mixer displayed as usual, only nothing could be heard. Asking Grub to boot my previous kernel - 2.6.29-r5 - instead did avoid the problem, so it's the new kernel driver.

I won't have the time to do stuff like git bisections for at least a month, so if anybody has a more direct suggestion as to how to avoid this, I'd be glad to know.

# lspci -s 01:0a -vv
01:0a.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
        Subsystem: Creative Labs SBLive! Player 5.1
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
                 Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
                <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (500ns min, 5000ns max)
        Interrupt: pin A routed to IRQ 21
        Region 0: I/O ports at b880 [size=32]
        Capabilities: [dc] Power Management version 1
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
                       PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: EMU10K1_Audigy
        Kernel modules: snd-emu10k1

01:0a.1 Input device controller: Creative Labs SB Live! Game Port (rev 07)
        Subsystem: Creative Labs Gameport Joystick
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
                 Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
                <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64
        Region 0: I/O ports at bc00 [size=8]
        Capabilities: [dc] Power Management version 1
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
                       PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: Emu10k1_gameport
        Kernel modules: emu10k1-gp

Relevant part of emerge --info:
Portage 2.2_rc33 (default/linux/x86/2008.0/desktop, gcc-4.3.3, glibc-2.10.1-r0, 2.6.29-gentoo-r5 i686)
=================================================================
System uname: Linux-2.6.29-gentoo-r5-i686-Intel-R-_Pentium-R-_4_CPU_3.00GHz-with-gentoo-2.0.1
Comment 1 BoyZonder 2009-06-17 17:08:01 UTC
(In reply to comment #0)
> After compiling and booting the 2.6.30-gentoo-r1 kernel, my sound card didn't
> produce any sound using the emu10k1 driver. Modueles were loaded and mixer
> displayed as usual, only nothing could be heard. Asking Grub to boot my
> previous kernel - 2.6.29-r5 - instead did avoid the problem, so it's the new
> kernel driver.

Are you sure your mixer settings are being restored correctly? I'm asking because I had a similar problem, where sound worked perfectly under 2.6.29.x, but didn't under 2.6.30. On my machine /etc/init.d/alsasound gave the following result with kernel 2.6.30:

alsasound          |* Restoring Mixer Levels...
alsasound          |Unknown hardware: "HDA-Intel" "Realtek ALC889A" "HDA:10ec0885,1458a002,00100101" "0x1458" "0xa102"
alsasound          |Hardware is initialized using a guess method
alsasound          |/usr/share/alsa/init/default:51: control element not found
alsasound          |/usr/share/alsa/init/default:52: missing closing brace for format
alsasound          |/usr/share/alsa/init/default:52: error parsing CTL attribute
alsasound          |/usr/share/alsa/init/default:52: invalid rule
alsasound          |* Errors while restoring defaults, ignoring

Moreover, I had no sound. At first I figured it must have something to do with the kernel driver, but closer inspection revelead that the mixer settings stored under 2.6.29 couldn't be loaded properly with 2.6.30 (due to ALSA change from 1.0.18a to 1.0.20), and the default was not appropriate for my setup (IEC958 being off by default). Simply setting the mixer settings manually with alsamixer and them storing them with '/etc/init.d/alsasound save' did the trick for me!
Comment 2 Martin von Gagern 2009-06-17 19:02:34 UTC
(In reply to comment #1)
> Are you sure your mixer settings are being restored correctly?

I'd almost answered "no" to this, as I had toyed around with the mixer for ten minutes at least before booting my old kernel. However, as I just rebooted the system with 2.6.30 to look for anything unusual in dmesg, I got sound, but only on the left channel. And indeed I did find the wave output at minimum for the right channel. So it might have been the mixer first time around as well. Adjusting Subject to reflect this.

> On my machine /etc/init.d/alsasound gave the following result with kernel
> 2.6.30:

No such messages on my system at this second reboot. Unfortunately I don't have the rc.log from my first boot into 2.6.30 around anymore.

> At first I figured it must have something to do with
> the kernel driver, but closer inspection revelead that the mixer settings
> stored under 2.6.29 couldn't be loaded properly with 2.6.30 (due to ALSA
> change from 1.0.18a to 1.0.20),

That part doesn't apply to me; I've got alsa 1.0.20 up and running for a month now. So I guess it was more likely the new kernel using a different identifier for the same device, or something like this.

> Simply setting the mixer settings manually with alsamixer and them storing
> them with '/etc/init.d/alsasound save' did the trick for me!

Did so now, will report back upon next reboot.
Comment 3 Martin von Gagern 2009-06-17 19:28:34 UTC
(In reply to comment #2)
> Did so now, will report back upon next reboot.

Looks good - or rather sounds good, to be precise.

Question is, how to deal with this before stabilizing the 2.6.30 sources. Is there any way I can provide additional information on this? Do you want to simply ewarn about the possibility of this bug occuring? Or is it enough that this bug report here exists, so people hitting the bug can find a solution?
Comment 4 BoyZonder 2009-06-18 06:15:47 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > Did so now, will report back upon next reboot.
> 
> Looks good - or rather sounds good, to be precise.
> 
> Question is, how to deal with this before stabilizing the 2.6.30 sources. Is
> there any way I can provide additional information on this? Do you want to
> simply ewarn about the possibility of this bug occuring? Or is it enough that
> this bug report here exists, so people hitting the bug can find a solution?

I have no suggestions regarding your last remark, but just wanted to point out that with the change of ALSA from 1.0.18 to 1.0.20 I meant the change in the drivers in kernels 2.6.29 and 2.6.30 (do 'cat /proc/asound/version') under the two kernel versions to see what I mean).
Comment 5 Martin von Gagern 2009-06-19 08:35:37 UTC
(In reply to comment #4)
> with the change of ALSA from 1.0.18 to 1.0.20 I meant the change in the
> drivers in kernels 2.6.29 and 2.6.30

Ah! OK, I had been referring to the versions of packages such as alsa-lib, 
alsa-plugins, alsa-headers and alsa-utils. In this case, I guess the change in ALSA version in the kernel code is a likely cause for me as well.

(In reply to comment #2)
> Unfortunately I don't have the rc.log from my first boot into 2.6.30 around
> anymore.

I've been wrong. OpenRC does append to that log, not replace it. So this here should be it:

* Restoring Mixer Levels...
Unknown hardware: "EMU10K1" "SigmaTel STAC9708,11" "AC97a:83847608" "0x1102" "0x8061"
Hardware is initialized using a guess method
/usr/share/alsa/init/default:51: control element not found
/usr/share/alsa/init/default:52: missing closing brace for format
/usr/share/alsa/init/default:52: error parsing CTL attribute
/usr/share/alsa/init/default:52: invalid rule
* Errors while restoring defaults, ignoring

Sounds very much like your messages from comment #1.
Comment 6 Lars Wendler (Polynomial-C) gentoo-dev 2009-06-21 17:09:37 UTC
This always happens when the ALSA-devs think it's time to change the mixer interface of some ALSA-drivers once again (which happens quite often).
I had this problem several times with my different emu10k1 cards over the last six years, so I'm quite sure there's nothing we can do to prevent such behavior.