Interrupt storm
Nate Lawson
nate at root.org
Thu Apr 7 10:44:53 PDT 2005
Antoine Brodin wrote:
> John Baldwin <jhb at FreeBSD.org> wrote:
>
>>On Tuesday 05 April 2005 02:41 pm, Antoine Brodin wrote:
>>
>>>John Baldwin <jhb at FreeBSD.org> 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?
>>>
>>>Without ACPI, sk0 gets irq 5 and it works ok.
>>>
>>>With your patch and ACPI, sk0 no longer timeouts, and it's usable.
>>>But I still have interrupt storms.
>>>dmesg: http://bsd.miki.eu.org/~antoine/current+acpi+patch.dmesg
>>
>>Well, all the interrupts are now routed the same as with the old ACPI code.
>>Perhaps, can you try commenting out the code that calls _DIS in
>>acpi_pci_link_attach()? Specifically, here:
>>And let me know if that makes a difference.
>
>
> Thanks ! That makes everything work well !
> Also, backing out your previous change and only #if0ing the code that
> calls _DIS makes everything work well too.
> So I guess the _DIS methods of my BIOS are the culprit.
I assume when we run _DIS on a link, we set a flag for that link saying
it is unrouted. (We can't trust _CRS to report this correctly so we
have to cache the value ourselves.) So we should explicitly re-route
all those links (with _SRS) sometime later. Is that not happening?
--
Nate
More information about the freebsd-current
mailing list