Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263241AbTKWDYW (ORCPT ); Sat, 22 Nov 2003 22:24:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263244AbTKWDYW (ORCPT ); Sat, 22 Nov 2003 22:24:22 -0500 Received: from fw.osdl.org ([65.172.181.6]:13738 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S263241AbTKWDYT (ORCPT ); Sat, 22 Nov 2003 22:24:19 -0500 Date: Sat, 22 Nov 2003 19:24:15 -0800 (PST) From: Linus Torvalds To: "Marco d'Itri" cc: Kernel Mailing List , Bartlomiej Zolnierkiewicz , Len Brown Subject: Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 In-Reply-To: <20031123021537.GA1816@wonderland.linux.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2486 Lines: 75 On Sun, 23 Nov 2003, Marco d'Itri wrote: > > It does not. This is the output with your patch applied and PCI > debugging enabled: Thanks. This is interesting. Looking at the IRQ probing output: > hdc: IRQ probe failed (0x3cfa: 0). Guessing at 15 The interesting parts are the 0x3cfa and the 0: - the "0" means that we literally didn't see any interrupt at all during the autoprobing. Sometimes autoprobing fails because we see _multiple_ interrupts, but that wasn't the case here. - 0x3cfa is the "probe cookie", which tells which irq's were free to be probed. That's 1, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 and what's interesting is that irq 15 wasn't even probed at all (14 wasn't either, but that's easy to explain: we took that when we probed and registered ide channel 0 earlier. irq 0 and 2 are special - timer and cascade respectively). So for some reason irq 15 has already been reserved. Somebody has already registered IRQ 15 _before_ we probe for it for that hwif. And: > irq 15: nobody cared! > Call Trace: > [ ... ] > handlers: > [] (ide_intr+0x0/0x130) this shows that the claimer of the irq is the IDE layer itself. But why has the IDE layer already claimed that interrupt? > Before receiving your second message I tried booting with pci=noacpi and > it worked: Interesting and good in the sense that this is another clue. Why does ACPI interrupt routing cause the IDE layer to register irq 15 too early? Both the PIRQ routing code and the ACPI code give irq3 to the other IDE chip. So why has the IDE stuff registered _another_ irq15 earlier? I don't see it.. Len, Bartlomiej, do you see anything? Marco, can you try this appended (very very stupid) patch with ACPI on, so that we can see where irq15 gets registered? It won't fix anything, but I'm confused by why IRQ 15 has been registered before we probe for it.. Thanks, Linus --- ===== arch/i386/kernel/irq.c 1.45 vs edited ===== --- 1.45/arch/i386/kernel/irq.c Wed Oct 22 20:26:34 2003 +++ edited/arch/i386/kernel/irq.c Sat Nov 22 19:22:20 2003 @@ -569,6 +569,8 @@ if (!action) return -ENOMEM; + WARN_ON(irq == 15); + action->handler = handler; action->flags = irqflags; action->mask = 0; - 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/