Re: Interrupt storm

On Friday 08 April 2005 08:10 am, Antoine Brodin wrote:
> John Baldwin <jhb_at_FreeBSD.org> wrote:
> > 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.
>
> Hi,
>
> I was wondering why ACPI pci link code from RELENG_5 worked (it called
> _DIS too) and I noticed this in my dmesg:
> - pci_link[0-14] are attached
> - then pci0, pcib0 and other devices are attached
> - then pci_link[15-31] are attached
> - then other devices are attached
>
> I thought that perhaps the problem was that _DIS was called after
> devices had already been attached and had allocated an irq.
>
> So I tried this patch:
>
> %%%
> Index: acpi_pci_link.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pci_link.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 acpi_pci_link.c
> --- acpi_pci_link.c     18 Jan 2005 20:18:46 -0000      1.44
> +++ acpi_pci_link.c     8 Apr 2005 11:19:29 -0000
> _at__at_ -511,7 +511,8 _at__at_ acpi_pci_link_attach(device_t dev)
>  	 * run _DIS (i.e., the method doesn't exist), assume the initial
>  	 * IRQ was routed by the BIOS. */
> -	if (ACPI_SUCCESS(AcpiEvaluateObject(acpi_get_handle(dev), "_DIS", NULL,
> +	if (device_get_unit(dev) <= 14 &&
> +	    ACPI_SUCCESS(AcpiEvaluateObject(acpi_get_handle(dev), "_DIS", NULL,
>  	    NULL)))
>  		for (i = 0; i < sc->pl_num_links; i++)
>  			sc->pl_links[i].l_irq = PCI_INVALID_IRQ;
> %%%
>
> With this patch, sk0 uses irq9 but everything works fine (no timeouts,
> no interrupt storms).
> I don't know if my idea is totally silly or not ...
> Perhaps the pci links should be all attached before other devices are
> attached ?

I think your other link devices are meant to be used in APIC mode (note their 
names start with 'A') and thus I think they are aliases for the other link 
devices.  So when I turn off the alias, I turn off the non-APIC mode one as 
well.  Working BIOSen handle this by having the same link device change its 
behavior (different _PRS return values) depending on the PIC mode.  It's not 
easy to determine if a link is just not used (for example, if no card is 
plugged into a slot with a dedicated link) or if it's an alias.  I think 
having two ACPI devices alias to the same hardware is a bug in the BIOS 
though.  Perhaps your BIOS vendor can be convinced to fix this.  Can you see 
if Linux has the same problem btw?

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