linux-kernel - Re: 4.7 regression: ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201609291848.33803.linux@rainbow-software.org>
Date:   Thu, 29 Sep 2016 18:48:32 +0200
From:   Ondrej Zary <linux@...nbow-software.org>
To:     Sinan Kaya <okaya@...eaurora.org>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
        linux-pci@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
        wim@....tudelft.nl, ravikanth.nalla@....com
Subject: Re: 4.7 regression: ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

On Thursday 29 September 2016 16:28:23 Sinan Kaya wrote:
> On 9/29/2016 9:49 AM, Ondrej Zary wrote:
> >> Ok, since I have not seen the full boot log I am guessing that isa api
> >>
> >> > gets called before the link objects are initialized.
> >
> > Netconsole did not work (probably because it crashes too early?) and I
> > don't have a null-modem cable.
>
> Probably, this is telling me that using the link list to determine
> penalties for ISA penalties is a bad idea as the ISA API seems to be called
> from arbitrary contexts even before the ACPI Link objects are created.
>
> I was trying to reuse the PCI execution path for ISA interrupts using the
> last two patches. I dropped the first and last two patches and restored the
> penalty PCI penalty assignment for the active interrupt only if the
> interrupt is a ISA interrupt with a new patch.
>
> >> > Can you appply the first three only (0001, 0002 and 0003) to see if it
> >> > makes a difference?
> >
> > It boots with first 3 patches only but the problem remains - see the
> > attached log.
>
> Let's see the new set. If this doesn't work, I'll have to provide you with
> another patch to get the penalty counts again. The original debug aids
> patch may not apply after these.

It boots but the IRQ problem still remains the same. See the attached logs:
dmesg-bad.txt: without the irq -> link->irq.active change
dmesg-bad2.txt: with the irq -> link->irq.active change
dmesg-bad2-debug.txt: as above with modified debug patch

@@ -876,8 +893,11 @@ void acpi_penalize_isa_irq(int irq, int active)
 {
        int penalty = active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING;

-       if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
+       if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty))) {
                acpi_isa_irq_penalty[irq] += penalty;
+               pr_info("%s:%d acpi_isa_irq_penalty[%d]=0x%x active = %d\n", 
__func__,
+                               __LINE__, irq,  acpi_irq_get_penalty(irq), 
active);
+       }
 }


-- 
Ondrej Zary

View attachment "dmesg-bad2-debug.txt" of type "text/plain" (33011 bytes)

View attachment "dmesg-bad2.txt" of type "text/plain" (28664 bytes)

View attachment "dmesg-bad.txt" of type "text/plain" (29179 bytes)