Bug 1531140

Created attachment 1377020 [details]
Mustang boot with acpi

I think this is a firmware bug uncovered by commit e361d1f85855ded967bd48 ("ACPI / scan: Fix enumeration for special UART devices").

That patch changed ACPI scanning to stop enumerating devices which are attached to serial busses (i2c, uart, etc).

Unfortunately, some firmwares for xgene-based platforms describe their uart devices in such a way that they appear to be attached devices rather than uarts.

On my mustang, I see this in the DSDT table:

       Device (URT0)
        {
            Name (_HID, "APMC0D08")  // _HID: Hardware ID
            Name (_DDN, "URT0")  // _DDN: DOS Device Name
            Name (_UID, "URT0")  // _UID: Unique ID
            Name (_CCA, One)  // _CCA: Cache Coherency Attribute
            Name (_STR, Unicode ("APM X-Gene UART0 Controller")) 
            ...
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                Memory32Fixed (ReadWrite,
                    0x1C020000,         // Address Base
                    0x00000100,         // Address Length
                    )
                UartSerialBusV2 (0x0001C200, DataBitsEight, StopBitsOne,
                    0x00, LittleEndian, ParityTypeNone, FlowControlNone,
                    0x0010, 0x0010, "URT0",
                    0x00, ResourceConsumer, , Exclusive,
                    )
                Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, )
                {
                    0x0000006C,
                }
            })

The UartSerialBusV2 resource tells the kernel that the uart controller is attached to a serial bus. The end result is that the kernel acpi doesn't register the uart. The proper solution is to remove the bogus UartSerialBusV2 resource(s) from the DSDT table.

Iyappan: can you provide any assistance around firmware?

Mark: is the fix to revert the change or is there another patch?

From kernel-side, revert is only thing right now. I started working on a patch to add a quirks list to the code so we can avoid the problem without having to revert the whole patch. But I got distracted (and was hoping for a firmware fix). I'll take another poke at it this evening.

Let's see how this goes:

https://lkml.org/lkml/2018/4/19/1020

Fixed pushed to rawhide (will be in 4.17rc2 build) and the next 4.16 build post 4.16.3-300

Proposed as a Freeze Exception for 28-final by Fedora user pbrobinson using the blocker tracking app because:

 This fixes a console regression on X-Gene plaforms booting ACPI like the HP m400 blades (for use on OpenQA) and the mustang.

Tested on mustang with acpi=force

Discussed at 2018-04-23 freeze exception review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2018-04-23/f28-blocker-review.2018-04-23-16.00.html . Accepted as a freeze exception issue: this can be a major issue during install on a significant supported platform, cannot be fully fixed with a post-release update.

kernel-4.16.3-301.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-b921ff4b1e

kernel-4.16.3-301.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.