From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759566AbXKNROE (ORCPT ); Wed, 14 Nov 2007 12:14:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754137AbXKNRNy (ORCPT ); Wed, 14 Nov 2007 12:13:54 -0500 Received: from cantor2.suse.de ([195.135.220.15]:40066 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752561AbXKNRNx (ORCPT ); Wed, 14 Nov 2007 12:13:53 -0500 Date: Wed, 14 Nov 2007 14:19:20 +0100 Message-ID: From: Takashi Iwai To: Roland Dreier Cc: linux-kernel@vger.kernel.org Subject: Re: snd_hda_intel 2.6.24-rc2 bug: interrupts don't always work on Lenovo X60s In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta28) (fuki) (+CVS-20070806) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At Wed, 14 Nov 2007 08:39:03 -0800, Roland Dreier wrote: > > > Roland Dreier wrote: > > > > > [ 2311.759856] ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 21 > > > > > [ 2311.759866] hda_intel: probe_mask set to 0x1 for device 17aa:2010 > > > > > [ 2311.759886] PCI: Setting latency timer of device 0000:00:1b.0 to 64 > > > > > [ 2312.911309] hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x003f000c > > > Anyway, could you try the patch below? As far as I see, it's the only > > part that may access PINCAP verb for that NID. > > This seems to help in that I don't see the "azx_get_response timeout" > message on every module load as I do with mainline, but I still see a > problem with a different cmd after a few load-unload cycles: What cmd more exactly? The below is GET_DIGI_CONVERT. So it must be related with SPDIF but it must be same as 2.6.23. Or do you happen to set CONFIG_SND_HDA_POWER_SAVE=y? Anyway I think there is no real problem with polling mode. The driver switches to it when the response from the hardware gets confused. Takashi > [ 257.503143] ACPI: PCI interrupt for device 0000:00:1b.0 disabled > [ 259.215359] ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 22 > [ 259.215372] hda_intel: probe_mask set to 0x1 for device 17aa:2010 > [ 259.215398] PCI: Setting latency timer of device 0000:00:1b.0 to 64 > [ 263.418591] ACPI: PCI interrupt for device 0000:00:1b.0 disabled > [ 265.626093] ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 22 > [ 265.626105] hda_intel: probe_mask set to 0x1 for device 17aa:2010 > [ 265.626133] PCI: Setting latency timer of device 0000:00:1b.0 to 64 > [ 320.898290] ACPI: PCI interrupt for device 0000:00:1b.0 disabled > [ 322.874182] ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 22 > [ 322.874196] hda_intel: probe_mask set to 0x1 for device 17aa:2010 > [ 322.874228] PCI: Setting latency timer of device 0000:00:1b.0 to 64 > [ 333.087177] ACPI: PCI interrupt for device 0000:00:1b.0 disabled > [ 334.024358] ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 22 > [ 334.024371] hda_intel: probe_mask set to 0x1 for device 17aa:2010 > [ 334.024395] PCI: Setting latency timer of device 0000:00:1b.0 to 64 > [ 335.422296] hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x002f0d00