Date: Thu, 07 Apr 2005 10:44:51 -0700 From: Nate Lawson <nate@root.org> To: Antoine Brodin <antoine.brodin@laposte.net> Cc: John Baldwin <jhb@FreeBSD.org> Subject: Re: Interrupt storm Message-ID: <42557193.1050805@root.org> In-Reply-To: <20050405214759.3921d21d.antoine.brodin@laposte.net> References: <b37cb09705032911295ce15f84@mail.gmail.com> <200504051349.13620.jhb@FreeBSD.org> <20050405204106.15e9d993.antoine.brodin@laposte.net> <200504051449.30871.jhb@FreeBSD.org> <20050405214759.3921d21d.antoine.brodin@laposte.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Antoine Brodin wrote: > John Baldwin <jhb@FreeBSD.org> wrote: > >>On Tuesday 05 April 2005 02:41 pm, Antoine Brodin wrote: >> >>>John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42557193.1050805>