Bug 1379946 - Linux 4.7: No IRQ available for PCI Interrupt Link [NEEDINFO]
Summary: Linux 4.7: No IRQ available for PCI Interrupt Link
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 24
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-28 08:15 UTC by Frank Mehnert
Modified: 2017-04-28 17:24 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-28 17:24:01 UTC
Type: Bug
Embargoed:
jforbes: needinfo?


Attachments (Terms of Use)

Description Frank Mehnert 2016-09-28 08:15:43 UTC
Description of problem:
There is a recent regression in the Linux 4.7 kernel which prevents other dvices from proper working if they share the IRQ9 (the ACPI IRQ). This happens only on systems without I/O-APIC because if the I/O-APIC is present, it's not necessary to share IRQ9.

This is a follow-up of https://www.virtualbox.org/ticket/15913 which is NOT a VirtualBox bug because we are able to reproduce the problem on real hardware. The problem happens more frequently with VirtualBox because for 32-bit guests we don't enable the I/O-APIC. Enabling the I/O-APIC for affected guests makes the problem go away.

Version-Release number of selected component (if applicable):
kernel-4.7.2-201.

How reproducible:
Boot Fedora 24 with the affected kernel on a system without an I/O-APIC. Passing 'noapic' as kernel parameter on a system with I/O-APIC will probably have the same effect. Then check if IRQ9 is used by ACPI and shared with another device. In our case it was the uhci_hcd and Linux couldn't detect corresponding USB devices. It is much easier to use VirtualBox and boot an up-to-date Fedora 24 guest (with Linux 4.7), disable the I/O-APIC and install the Guest Additions. IRQ9 will then be most likely shared with the VirtualBox VMM Device and actions taken on that device, for example using a shared folder, will not work (i.e. hang).

The kernel also prints the following message: "ACPI: No IRA available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off".

Steps to Reproduce:
1. Boot Fedora 24 with I/O-APIC disabled, either in a VM or pass 'noapic' as kernel parameter
2. Check that IRQ9 is shared between ACPI and another device
3. Check that the shared device on IRQ9 does not work properly

Actual results:
The shared device does not properly work. E.g. no USB device detected if the device is an USB driver or shared folders hang if the device is the VBox VMM device and the Guest Additions are installed.

Expected results:
The device which uses IRQ9 together with ACPI should work properly. This is no problem with Linux 4.6.

Additional info:
https://www.virtualbox.org/ticket/15913
Linux 4.7 did a lot of ACPI rework and I guess this was not properly tested on systems without I/O-APICs.

Comment 1 Frank Mehnert 2016-09-28 08:20:05 UTC
Typo: Of course the kernel message is "ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off". See drivers/acpi/pci_link.c function acpi_pci_link_allocate().

Comment 2 Michael Thayer 2016-10-05 15:12:49 UTC
We have done a bit of further analysis. It is indeed acpi_irq_get_penalty() preventing sharing because irq_get_trigger_type() returns zero. However, that is incorrect because the ACPI specification requires the SCI to be a level-triggered, active-low interrupt, shareable with PCI devices.

We suspect that the ACPI code fails to convey the SCI type information during initialization in the case where there's no I/O APIC and no MADT. When an I/O APIC and MADT are in place, the routine acpi_sci_ioapic_setup() in arch/x86/kernel/acpi/boot.c appears to do the work of setting the SCI type.

Comment 3 Michael Thayer 2016-10-11 07:37:01 UTC
Rafael Wysocki told me that this is will be fixed "for 4.9-rc1 and 4.8.y/4.7.y".  We found what we presume to be the relevant patchwork discussion<1>.  We will confirm when we have tested an updated kernel.

<1> https://patchwork.kernel.org/patch/9357253/

Comment 4 Justin M. Forbes 2017-04-11 14:48:49 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs.

Fedora 25 has now been rebased to 4.10.9-100.fc24.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26.

If you experience different issues, please open a new bug report for those.

Comment 5 Justin M. Forbes 2017-04-28 17:24:01 UTC
*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the 
relevant data from the latest kernel you are running and any data that might have been requested previously.


Note You need to log in before you can comment on or make changes to this bug.