Re: Interrupt storm

On Thursday 07 April 2005 01:43 pm, Nate Lawson wrote:
> John Baldwin wrote:
> > 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",
>
> When link devices are uninitialized by the BIOS, you usually get an
> invalid IRQ (i.e. 255 or 0).  However, there are some cases where you
> get a valid PCI irq but invalid for this system (i.e. not in the
> supported ones advertised by _PRS).  For instance, you might get a value
> of 15 for a link that only supports 3,4,5,6,7,9, etc.  I think you
> should be checking _PRS for validity, not just PCI_INTERRUPT_VALID (i.e.
> !255).  Aren't you doing that already?

Yes, I am.  However, what this is doing is going and looking to see if the 
BIOS has programmed a valid IRQ into any of the devices routed by this IRQ, 
and if so, we (currently) trust what the BIOS says over what the link claims 
as far as what the best IRQ to use is.  If the BIOS is just confused but the 
BIOS IRQ is still valid in _PRS then the fact that we always do an _SRS means 
we are still ok.  The real problem here is that for this machine, calling 
_DIS seems to permanently break the link devices.  I think we'll have to add 
a quirk to disable calling _DIS.  I wonder if Linux already has such a quirk 
for this box or if they are more selective about how and when they call _DIS.

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