linux-kernel - problem with codec discovery on HP 2530p

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20091110145338.A55E719D7AD@rover.gag.com>
Date:	Tue, 10 Nov 2009 09:53:38 -0500 (EST)
From:	bdale@....com (Bdale Garbee)
To:	linux-kernel@...r.kernel.org, tiwai@...e.de
Subject: problem with codec discovery on HP 2530p

I recently moved from 2.6.30.9 to the 2.6.32-rcX series on my HP EliteBook 
2530p.  Audio didn't work, and I've finally made time to track down the 
problem.  It turns out the problem actually started with 2.6.31-rc1, due
to a patch that was part of the 2.6.30-rcX series but apparently wasn't in
the 2.6.30 stable release.  

The symptom is:

HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
HDA Intel 0000:00:1b.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
HDA Intel 0000:00:1b.0: irq 30 for MSI/MSI-X
HDA Intel 0000:00:1b.0: setting latency timer to 64
hda-intel: Codec #0 probe error; disabling it...
hda-intel: spurious response 0x0:0x0, last cmd=0x0f0000
hda-intel: no codecs initialized
hda-intel: spurious response 0x0:0x0, last cmd=0x0f0000
HDA Intel 0000:00:1b.0: PCI INT A disabled

The codec in this machine is an AD1984A.  Bisecting, I discovered that 
reverting this single commit fixes things for me in 2.6.32-rc6:

8174086167d43d0fd7b21928074145ae1d15bbab is the first bad commit
commit 8174086167d43d0fd7b21928074145ae1d15bbab
Author: Takashi Iwai <tiwai@...e.de>
Date:   Tue May 26 15:22:00 2009 +0200

    ALSA: hda - Allow concurrent RIRB access in single_cmd mode

    In the single_cmd mode, the current driver code doesn't do any update
    for RIRB just for any safety reason.  But, actually the RIRB and
    single_cmd mode don't conflict.  Unsolicited events can be delivered
    even while using the single_cmd mode.

    This patch allows the handling of unsolicited events with single_cmd
    mode, just always checking RIRB independent from single_cmd flag.

    Signed-off-by: Takashi Iwai <tiwai@...e.de>

:040000 040000 f4fa70b3ac4fe54d436c59c26c9fe6754625953e 65ff495d67e60d2cf33bf9ea994a0a828d367284 M	sound

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/