Bug 1459186

Summary:	quirks patch 4.11 kernel for HP m400 to disable interrupt producer/consumer check
Product:	[Fedora] Fedora	Reporter:	Jeff Bastian <jbastian>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	medium
Version:	27	CC:	extras-qa, gansalmon, ichavero, itamar, jbastian, jcm, jlinton, jonathan, joseph.shifflett, kernel-maint, labbott, linda.knippers, madhu.chinakonda, mchehab, mknutson, msalter, pbrobinson, sgehwolf, thomas.palmer, tphan, trinh.dao
Target Milestone:	---	Flags:	jforbes: needinfo?
Target Release:	---
Hardware:	aarch64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1285107	Environment:
Last Closed:	2018-08-29 15:16:59 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1045641

Description Jeff Bastian 2017-06-06 13:31:17 UTC

+++ This bug was initially created as a clone of Bug #1285107 +++

Please apply the patch below to remove a check on interrupt producer/consumer values.  This is a quirk patch to workaround a bug in the HP m400 ACPI tables.


--- Additional comment from Jeff Bastian on 2017-05-25 16:17:17 CDT ---

I tested with Fedora-26-20170523.n.0 and kernel-4.11.0-2.el7.aarch64 gets past the problems seen in bug 1285107 comment 29, but it hangs later in boot.

EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.11.0-2.fc26.aarch64 (mockbuild.fedoraproject.org) (gcc version 7.1.1 20170503 (Red Hat 7.1.1-1) (GCC) ) #1 SMP Tue May 9 15:09:58 UTC 2017
...
[    0.000000] ACPI: RSDP 0x0000004FF8000000 000024 (v02 HP    )
[    0.000000] ACPI: XSDT 0x0000004FF7FF0000 000084 (v01 HP     ProLiant 00000001      01000013)
[    0.000000] ACPI: FACP 0x0000004FF7FB0000 000114 (v06 HPE    ProLiant 00000001 HP   00000001)
...
[    0.000000] Kernel command line: BOOT_IMAGE=(tftp)/F26-20170523.n.0/vmlinuz vnc repo=http://10.0.0.1/F26-20170523.n.0/ console=ttyS0,9600 earlycon=uart,mmio32,0x1c021000 verbose debug
...
[   17.494298] xgene-gpio APMC0D14:00: X-Gene GPIO driver registered.
[   17.568313] pcieport 0000:00:00.0: can't derive routing for PCI INT A
[   17.645381] pcieport 0000:00:00.0: PCI INT A: no GSI
[   17.704898] pcie_pme: probe of 0000:00:00.0:pcie001 failed with error -22
[   17.786673] GHES: Failed to enable APEI firmware first mode.
[   17.854865] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[   17.954600] dw-apb-uart APMC0D08:00: cannot get irq


This is as far as it gets into booting.

--- Additional comment from Mark Salter on 2017-05-26 09:54:48 CDT ---

This is the problem Jeremy Linton found:

"4.11 integrated patches for the MBIGEN interrupt controller, as part of this work additional checks were added in various places. One check in particular verifies that the interrupt producer/consumer direction is correct. This breaks the HP M400 serial console devices which makes the machine appear to fail to boot.
    
The correct fix for this is updated ACPI tables, in the interim lets patch the kernel so testing/qa/etc can continue."

The only workaround is to patch kernel:

diff --git a/drivers/acpi/irq.c b/drivers/acpi/irq.c
index 830299a..fec7d2b 100644
--- a/drivers/acpi/irq.c
+++ b/drivers/acpi/irq.c
@@ -200,8 +200,6 @@ static acpi_status acpi_irq_parse_one_cb(struct acpi_resource *ares,
                return AE_CTRL_TERMINATE;
        case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
                eirq = &ares->data.extended_irq;
-               if (eirq->producer_consumer == ACPI_PRODUCER)
-                       return AE_OK;
                if (ctx->index >= eirq->interrupt_count) {
                        ctx->index -= eirq->interrupt_count;
                        return AE_OK;

Comment 1 Laura Abbott 2018-02-28 03:54:50 UTC

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale. The kernel moves very fast so bugs may get fixed as part of a kernel update. Due to this, we are doing a mass bug update across all of the Fedora 26 kernel bugs.
 
Fedora 26 has now been rebased to 4.15.4-200.fc26.  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 27, and are still experiencing this issue, please change the version to Fedora 27.
 
If you experience different issues, please open a new bug report for those.

Comment 2 Jeff Bastian 2018-03-01 22:33:53 UTC

I'm not sure how it works, but 4.15.7-300.fc27 boots ok for me on the HP m400:

[root@hp-moonshot-03-c01 ~]# uname -r
4.15.7-300.fc27.aarch64

[root@hp-moonshot-03-c01 ~]# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.15.7-300.fc27.aarch64 root=/dev/mapper/rhel_hp--moonshot--03--c01-root ro crashkernel=auto rd.lvm.lv=rhel_hp-moonshot-03-c01/root rd.lvm.lv=rhel_hp-moonshot-03-c01/swap LANG=en_US.UTF-8 earlycon=uart,mmio32,0x1c021000 console=ttyS0,9600 ghes.disable=1


The Fedora 27 installation media fails to boot, though, since it was still a 4.13 based kernel:

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.13.9-300.fc27.aarch64 (mockbuild.fedoraproject.org) (gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)) #1 SMP Mon Oct 23 13:33:18 UTC 2017
...
[    0.000000] Kernel command line: BOOT_IMAGE=/images/hp-moonshot-03-c10/kernel console=ttyS0,9600 earlycon=uart,mmio32,0x1c021000 ghes.disable=1 ks=ks.cfg ksdevice=bootif netboot_method=grub2
...
[   18.725356] GHES: GHES is not enabled!
[   18.770206] ACPI GTDT: [Firmware Bug]: failed to get the Watchdog base address.
[   18.858147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[   18.966699] dw-apb-uart APMC0D08:00: cannot get irq

And it hangs here.

Hopefully this will be fixed in Fedora 28 which will have the newer kernel on the installation media.

Comment 3 Justin M. Forbes 2018-07-23 15:24:33 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 27 kernel bugs.

Fedora 27 has now been rebased to 4.17.7-100.fc27.  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 28, and are still experiencing this issue, please change the version to Fedora 28.

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

Comment 4 Justin M. Forbes 2018-08-29 15:16:59 UTC

*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 5 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.