The (dev->irq && dev->irq >= 0xF) comparison in the code snippet below should read (dev->irq && dev->irq <= 0xF), if the comments are correct. This is taken from line 356 or so in drivers/acpi/pci_irq.c. I haven't personally noticed any problems caused by this, but stumbled over it when looking for a way to get my Libretto 100CT's CardBus interface to give a IRQ to a USB card. Relevant code: /* * No IRQ known to the ACPI subsystem - maybe the BIOS / * driver reported one, then use it. Exit in any case. */ if (!irq) { printk(KERN_WARNING PREFIX "No IRQ known for interrupt pin %c of device %s", ('A' + pin), pci_name(dev)); /* Interrupt Line values above 0xF are forbidden */ if (dev->irq && dev->irq >= 0xF) { printk(" - using IRQ %d\n", dev->irq); return_VALUE(dev->irq); } else { printk("\n"); return_VALUE(0); } }
For your cardbus IRQ issue, please try the patch in http://bugme.osdl.org/attachment.cgi?id=1629&action=view.
Created attachment 2682 [details] the fix Comments were correct, code was incorrect. Here's the fix -- and it works: pci_link-0414 [26] acpi_pci_link_set : Link disabled ACPI: Unable to set IRQ for PCI Interrupt Link [PRQ7] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing. Try pci=noacpi or acpi=off pci_irq-0262 [23] acpi_pci_irq_lookup : Invalid IRQ link routing entry pci_irq-0316 [22] acpi_pci_irq_derive : Unable to derive IRQ for device 0000:02:07.0 ACPI: No IRQ known for interrupt pin A of device 0000:02:07.0 - using IRQ 11
closing shipped in 2.6.6 and on top of 2.4.27-pre2