Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262767AbUCMBw4 (ORCPT ); Fri, 12 Mar 2004 20:52:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262977AbUCMBw4 (ORCPT ); Fri, 12 Mar 2004 20:52:56 -0500 Received: from fmr05.intel.com ([134.134.136.6]:24218 "EHLO hermes.jf.intel.com") by vger.kernel.org with ESMTP id S262767AbUCMBwv (ORCPT ); Fri, 12 Mar 2004 20:52:51 -0500 Subject: Re: ALSA via82xx fails since 2.6.2 From: Len Brown To: =?ISO-8859-1?Q?J=FCrgen?= Repolusk Cc: linux-kernel@vger.kernel.org In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 Organization: Message-Id: <1079142765.2175.71.camel@dhcppc4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 12 Mar 2004 20:52:46 -0500 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4904 Lines: 139 On Fri, 2004-03-12 at 15:34, J?rgen Repolusk wrote: > I see this in dmesg on 2.6.4-rc1: > > VIA 82xx Audio: probe of 0000:00:07.5 failed with error -16 > I don't know if it is related to the audio failure, but interrupts in general and the ACPI SCI in particular seem totally broken on this box (below) > this is on a sony vaio pcg-fx505 > > regards > juergen repolusk, please CC me personally > > complete dmesg (+lspci follow) > ADT (v001 SONY K5 0x06040000 PTL_ 0x000f4240) @ 0x0fefee4c > ACPI: BOOT (v001 PTLTD $SBFTBL$ 0x06040000 LTP 0x00000001) @ > 0x0fefeec0 > ACPI: SSDT (v001 PTLTD POWERNOW 0x06040000 LTP 0x00000001) @ > 0x0fefeee8 > ACPI: DSDT (v001 SONY K5 0x06040000 MSFT 0x0100000d) @ > 0x00000000 > Built 1 zonelists > Kernel command line: BOOT_IMAGE=gentoo264 ro root=303 apm=off acpi=on > vga=0x318 > Local APIC disabled by BIOS -- reenabling. > Found and enabled local APIC! > Initializing CPU#0 > PID hash table entries: 2048 (order 11: 16384 bytes) > Detected 1200.077 MHz processor. > Using tsc for high-res timesource > Console: colour dummy device 80x25 > Memory: 254264k/262144k available (2817k kernel code, 7056k reserved, > 1078k > data, 172k init, 0k highmem) > Checking if this processor honours the WP bit even in supervisor > mode... Ok. > Calibrating delay loop... 2359.29 BogoMIPS > Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) > Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) > Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > CPU: After generic identify, caps: 0383fbff c1cbfbff 00000000 > 00000000 > CPU: After vendor identify, caps: 0383fbff c1cbfbff 00000000 > 00000000 > CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) > CPU: L2 Cache: 256K (64 bytes/line) > CPU: After all inits, caps: 0383fbff c1cbfbff 00000000 00000020 > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#0. > CPU: AMD mobile AMD Athlon(tm) 4 stepping 02 > Enabling fast FPU save and restore... done. > Enabling unmasked SIMD FPU exception support... done. > Checking 'hlt' instruction... OK. > POSIX conformance testing by UNIFIX > enabled ExtINT on CPU#0 > ESR value before enabling vector: 00000000 > ESR value after enabling vector: 00000000 > Using local APIC timer interrupts. > calibrating APIC timer ... > ..... CPU clock speed is 1199.0872 MHz. > ..... host bus clock speed is 199.0978 MHz. > NET: Registered protocol family 16 > PCI: PCI BIOS revision 2.10 entry at 0xfd7cd, last bus=1 > PCI: Using configuration type 1 > mtrr: v2.0 (20020519) > ACPI: Subsystem revision 20040211 > ACPI: IRQ9 SCI: Level Trigger. > spurious 8259A interrupt: IRQ7. Spurious on IRQ7 may mean that a device is pulling an interrupt line which has no driver attached. > irq 9: nobody cared! > Call Trace: > [] __report_bad_irq+0x2b/0x90 > [] acpi_irq+0xf/0x1a > [] note_interrupt+0x64/0xa0 > [] do_IRQ+0x143/0x160 > [] common_interrupt+0x18/0x20 Here we've apparently gone recursive on the interrupt handler, I don't think that is supposed to be possible. > [] do_softirq+0x44/0xa0 > [] acpi_irq+0x0/0x1a > [] do_IRQ+0x117/0x160 > [] common_interrupt+0x18/0x20 > [] setup_irq+0x9c/0x100 > [] acpi_irq+0x0/0x1a okay, so we got an acpi_irq() right when we requeted the IRQ, that is unusual, but should be okay. Curious that common_interrupt/do_IRQ are not on the stack here though... > [] request_irq+0x98/0xd0 > [] acpi_os_install_interrupt_handler+0x35/0x5b > [] acpi_irq+0x0/0x1a > [] acpi_irq+0x0/0x1a dunno what's the deal with the stack here acpi_irq() is not called from acpi_ev_install_sci_handler(), and request_irq() hasn't even been called yet! > [] acpi_ev_install_sci_handler+0x1d/0x1f > [] acpi_ev_sci_xrupt_handler+0x0/0x1c > [] acpi_ev_handler_initialize+0x9/0x71 > [] acpi_enable_subsystem+0x2e/0x5b > [] acpi_bus_init+0x7c/0x111 > [] acpi_init+0x59/0xb4 > [] do_initcalls+0x2c/0xa0 > [] init_workqueues+0x12/0x30 > [] init+0x35/0x140 > [] init+0x0/0x140 > [] kernel_thread_helper+0x5/0xc > > handlers: > [] (acpi_irq+0x0/0x1a) > Disabling IRQ #9 > ACPI: Interpreter enabled What does /proc/interrupts on this box look like? how about when you boot with acpi=off or pci=noacpi? Are you sure you didn't see these messages before 2.6.2 -- was ACPI enabled in the working release? thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/