Mouse integration does not work with Linux 4.8 guest without I/O APIC

[Jeremy Bícha]

My host and guest is Ubuntu 16.10 64-bit.

I can't use my mouse to click anything inside the Ubuntu (Unity) 16.10 guest. A workaround is to (install if necessary and) select the older yakkety Linux 4.4 kernel from the grub boot screen in the guest.

Or open the VM Settings. Switch to the System tab and make sure "Enable I/O APIC" is turned on. This setting is recommended by VirtualBox:
https://www.virtualbox.org/manual/ch03.html#intro-64bitguests

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: virtualbox 5.1.6-dfsg-2
ProcVersionSignature: Ubuntu 4.8.0-17.19-generic 4.8.0-rc7
Uname: Linux 4.8.0-17-generic x86_64
ApportVersion: 2.20.3-0ubuntu7
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Oct 3 01:53:20 2016
EcryptfsInUse: Yes
InstallationDate: Installed on 2016-08-11 (52 days ago)
InstallationMedia: Ubuntu-GNOME 16.10 "Yakkety Yak" - Alpha amd64 (20160811)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: virtualbox
UpgradeStatus: No upgrade log present (probably fresh install)

[Frank (frank-redhat-bugs)]

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.

[Frank (frank-redhat-bugs)]

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().

[Gianfranco Costamagna (costamagnagianfranco)]

Seems a kernel bug
https://bugzilla.redhat.com/show_bug.cgi?id=1379946

[Michael (michael-redhat-bugs)]

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.

[Michael (michael-redhat-bugs)]

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/

[Justin (justin-redhat-bugs)]

*********** 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.

[Justin (justin-redhat-bugs)]

*********** 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.