From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760152AbXKLRWw (ORCPT ); Mon, 12 Nov 2007 12:22:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759422AbXKLRWm (ORCPT ); Mon, 12 Nov 2007 12:22:42 -0500 Received: from ns.suse.de ([195.135.220.2]:53436 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759181AbXKLRWl (ORCPT ); Mon, 12 Nov 2007 12:22:41 -0500 Date: Mon, 12 Nov 2007 14:41:50 +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 Mon, 12 Nov 2007 08:59:49 -0800, Roland Dreier wrote: > > > You seem to pass unneeded module options to snd-hda-intel driver like > > MSI enablement. First, try to remove all these options. > > Yes, it's trivial to reproduce without any options: > > [ 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 Hm, strange, NID 0x03 shouldn't be accessed via AD1981 codec, at least, thinkpad model. Did you enable CONFIG_SND_HDA_CODEC_ANALOG? Otherwise it won't work. > (By the way, what's wrong with using the enable_msi option? MSI seems > very solid on Intel platforms, and I prefer avoiding shared interrupts) It may work, but first we need to make sure that we're seeing the same problem. MSI is one of the unstable factors for many platforms, thus the driver tries to disable MSI first if any sign of wrong irqs is found. Takashi