Description:
"Disabling IRQ #18" began to appear after upgrading to kernel 2.6.22. After a little research, this turned out to be my NIC, with the error breaking network access. I had no such problems prior to the upgrade.

Additional info:
While I don't have a copy of a full dmesg, I have outputs of grep irq and grep IRQ.

####################
# dmesg | grep irq #
####################
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 controller doesn't have AUX irq; using default 12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001fc00 irq 14
ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001fc08 irq 15
sata_via 0000:00:0f.0: routed to hard irq line 10
ata3: SATA max UDMA/133 cmd 0x0001ef88 ctl 0x0001ef86 bmdma 0x0001eeb0 irq 16
ata4: SATA max UDMA/133 cmd 0x0001ef68 ctl 0x0001ef82 bmdma 0x0001eeb8 irq 16
uhci_hcd 0000:00:10.0: irq 17, io base 0x0000eec0
uhci_hcd 0000:00:10.1: irq 17, io base 0x0000ef00
uhci_hcd 0000:00:10.2: irq 17, io base 0x0000ef20
uhci_hcd 0000:00:10.3: irq 17, io base 0x0000ef40
ehci_hcd 0000:00:10.4: irq 17, io mem 0xfe600000
irq 18: nobody cared (try booting with the "irqpoll" option)
[<c0157434>] __report_bad_irq+0x24/0x80
[<c0157de7>] handle_fasteoi_irq+0x87/0xe0

####################
# dmesg | grep IRQ #
####################
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
ENABLING IO-APIC IRQs
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs *3 4 5 7 10 11 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 *10 11 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 7 10 11 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
PCI: Using ACPI for IRQ routing
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
ACPI: PCI Interrupt 0000:00:0f.1[A] -> GSI 20 (level, low) -> IRQ 16
ACPI: PCI Interrupt 0000:00:0f.0[b] -> GSI 20 (level, low) -> IRQ 16
ACPI: PCI Interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:00:10.1[A] -> GSI 21 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:00:10.2[b] -> GSI 21 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:00:10.3[b] -> GSI 21 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:00:10.4[C] -> GSI 21 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:00:0e.0[A] -> GSI 17 (level, low) -> IRQ 18
eth0: ADMtek Comet rev 17 at Port 0xe400, <MAC address>, IRQ 18. # Network card
ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 16 (level, low) -> IRQ 19
ACPI: PCI Interrupt 0000:00:11.6[C] -> GSI 22 (level, low) -> IRQ 20
ACPI: PCI Interrupt 0000:00:11.5[C] -> GSI 22 (level, low) -> IRQ 20
ACPI: Unable to derive IRQ for device 0000:00:0a.2
[<c0156960>] handle_IRQ_event+0x30/0x60
[<c0106f4b>] do_IRQ+0x3b/0x70
Disabling IRQ #18

The option "irqpoll" doesn't help, but I have no problems when running with "noirqdebug." I have suspicions that this problem may be messing with wine, as the same ludicrous wait times as here are reproduced:
http://bugs.archlinux.org/task/7627?histring=wine

First time bug reporting, hope I didn't miss anything.