On Wed, Dec 03, 2008 at 09:49:20AM +0100, Jiri Slaby wrote: > On 12/03/2008 09:06 AM, Grant Grundler wrote: > > On Tue, Dec 02, 2008 at 09:52:09PM +0100, Jiri Slaby wrote: > >> Hi, > >> > >> is this dmesg snippet correct? > > > > Which kernel? Which architecture? > > 2.6.27, x86 > > > Some architectures also dump ACPI (or other) Interrupt routing table > > information early in the boot. > > acpi=noirq, I noted that below. What exactly do you need to know? The source of the IRQ and the Interrupt routes used. > Step aside, acpi prt table is probably borked, it assigns irq 11 to the device > which causes irq 10 nobody cared message. I need to play with this further, > that bios seems to be unconceivably broken. Yeah, I was wondering if the IRQ # can be configured with a BIOS setup menu. Sounds like it's not an option. Have you seen the "acer_tm360_irqrouting" hack in pcibios_lookup_irq()? (still in arch/x86/pci/irq.c). I'm wondering if your platform needs that as well. Which vendor and model of machine is this? > >> PCI: setting IRQ 2 as level-triggered > > > > Assuming x86, the above line is printed by eisa_set_level_irq(). > > (See arch/x86/pci/irq.c) > > Yes. The 2 is read somewhere from ISA bridge device configspace. That's what I wanted to know...can you dump the "raw" value? > > A function called "eisa_foo" printing a "PCI:" prefix? > > > > > >> serial 0000:00:09.0: found PCI INT A -> IRQ 2 > > > > I can't find the code which outputs this line in current > > linux-2.6 source tree. I looked for "%s: found" and > > also looked for dev_printk() with "PCI" or "found". > > msg = "found"; :) > from > arch/x86/pci/irq.c ah - ok. Just before the call to eisa_set_level_irq(). > > I suspect "2" is the APIC input line and not the linux global > > interrupt value (10). Again, code is probably correct but not the > > labeling of the output. > > > >> 0000:00:09.0: ttyS4 at I/O 0x1898 (irq = 10) is a 16550A > >> 0000:00:09.0: ttyS5 at I/O 0x1890 (irq = 10) is a 16550A > >> > >> This is acpi=noirq and it works fine (dev->irq is 10). Shouldn't it show and > >> enable IRQ 10 instead of the one found by pirq, i.e. 2 (VIA router)? > > > > Since you say it's working, it's probably enabling global interrupt 10. > > I agree it should be showing the same value if it's after all the > > architecture fix up's have been applied to the dev->irq. > > Actually it enables nothing, it is unused (apart from printing out) > as far as I can tell. Enabling (of proper irq) on (A)PIC is done > through request_irq. "enables" was a bad choice - "sets up" would have been better. > And while it is > ACPI: Using PIC for interrupt routing This wasn't in the output you posted before. Can you post the entire dmesg output? Or post a link if you feel the entire output is too long. > and 2 is a cascading pin of master pic, I would say this is wrong :). If it's using the classic 8259 PIC, I agree. hth, grant -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
