Re: Interrupt storm

On Tuesday 05 April 2005 12:58 pm, Antoine Brodin wrote:
> John Baldwin <jhb_at_FreeBSD.org> wrote:
> > On Saturday 02 April 2005 04:41 pm, Antoine Brodin wrote:
> > > Nate Lawson <nate_at_root.org> wrote:
> > > > I'm a little confused.  I don't know of anyone that has problems with
> > > > the 6-current PCI irq code that works on 5-stable (which is what your
> > > > cvs command updates it to).
> > > >
> > > > Do either of you have a problem with irq routing on 6-current that
> > > > works on 5-stable?  Please send details if so.
> > >
> > > Hi,
> > >
> > > I have this problem too, but since it's on a desktop I didn't really
> > > care about acpi.
> > >
> > > Here are some details:
> > >
> > > current with pci irq code from 23-Nov-2004 dmesg:
> > > http://bsd.miki.eu.org/~antoine/current+oldacpi.dmesg
> > >
> > > current with current pci irq code dmesg:
> > > http://bsd.miki.eu.org/~antoine/current+acpi.dmesg
> > > (there are timeouts and interrupt storms)
> > >
> > > acpi tables and asl:
> > > http://bsd.miki.eu.org/~antoine/acpidump
> >
> > So the differences in actual IRQ assignments look like this:
> >
> > 13c13
> > < pcib1: slot 4 INTA routed to irq 5 via \\_SB_.PCI0.LNK2
> > ---
> >
> > > pcib1: slot 4 INTA routed to irq 9 via \\_SB_.PCI0.LNK2
> >
> > 15,16c15,16
> > < pcib1: slot 7 INTA is already routed to irq 12
> > < pcib1: slot 10 INTA routed to irq 11 via \\_SB_.PCI0.LNK1
> > ---
> >
> > > pcib1: slot 7 INTA routed to irq 12 via \\_SB_.PCI0.LNK4
> > > pcib1: slot 10 INTA routed to irq 12 via \\_SB_.PCI0.LNK1
> >
> > That is, LNK2 is routed to 9 rather than 5 and LNK1 is routed to 12
> > rather than 11.
> >
> > I'm not sure why it does this unless somehow the wrong device_t is
> > getting associated with a handle.
> >
> > > grep 'LNK[12]' current+acpi.dmesg
> >
> > pci_link10: <ACPI PCI Link LNK1> irq 11 on acpi0
> > pci_link11: <ACPI PCI Link LNK2> irq 5 on acpi0
> > pcib1: matched entry for 1.4.INTA (src \\_SB_.PCI0.LNK2:0)
> > pcib1: slot 4 INTA routed to irq 9 via \\_SB_.PCI0.LNK2
> > pcib1: matched entry for 1.10.INTA (src \\_SB_.PCI0.LNK1:0)
> > pcib1: slot 10 INTA routed to irq 12 via \\_SB_.PCI0.LNK1
> >
> > Can you apply this patch and provide a non-verbose dmesg?
>
> Here it is:
> http://bsd.miki.eu.org/~antoine/current+acpi+semiverbose.dmesg

Ok, I see the issue now.  The problem is that the BIOS sets the IRQ registers 
in the PCI devices to values that don't match how the links are programmed 
and we tend to trust the BIOS over the links in those cases.  Can you tell me 
what IRQ sk0 gets if you don't use ACPI?  Does it get 5 or 9?  If it gets 9, 
does it work ok?

You can try this patch for ACPI.  Unfortunately, some BIOSes lie when you ask 
a link which IRQ it is routed to, so I'm not sure if this patch can be 
committed as is.  Nate, do you know if such BIOSen only return no IRQ at all 
(0 or 255) when they lie rather than a bogus "valid" IRQ?

--- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_pci_link.c	2005/01/18 
20:21:25
+++ //depot/user/jhb/acpipci/dev/acpica/acpi_pci_link.c	2005/04/05 17:46:46
_at__at_ -621,14 +622,16 _at__at_
 		device_printf(dev, "BIOS IRQ %u for %d.%d.INT%c is invalid\n",
 		    bios_irq, pcib_get_bus(pcib), slot, pin + 'A');
 	} else if (!PCI_INTERRUPT_VALID(link->l_bios_irq)) {
-		link->l_bios_irq = bios_irq;
-		if (bios_irq < NUM_ISA_INTERRUPTS)
-			pci_link_bios_isa_irqs |= (1 << bios_irq);
 		if (bios_irq != link->l_initial_irq &&
 		    PCI_INTERRUPT_VALID(link->l_initial_irq))
 			device_printf(dev,
 			    "BIOS IRQ %u does not match initial IRQ %u\n",
 			    bios_irq, link->l_initial_irq);
+		else {
+			link->l_bios_irq = bios_irq;
+			if (bios_irq < NUM_ISA_INTERRUPTS)
+				pci_link_bios_isa_irqs |= (1 << bios_irq);
+		}
 	} else if (bios_irq != link->l_bios_irq)
 		device_printf(dev,
 	    "BIOS IRQ %u for %d.%d.INT%c does not match previous BIOS IRQ %u\n",

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org