Description of problem: Attempting to boot 4.15.0-0.rc6.git0.1.fc28.aarch64 with acpi on the mustang provides no output on serial console. The system boots and is reachable on the network through ssh. Adding console=ttyS0,115200 didnt help. Version-Release number of selected component (if applicable): 4.15.0-0.rcX Actual results: Only prints initial EFI messages: EFI stub: Booting Linux Kernel... EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... L3C: 8MB Additional info: On shutdown there is a kernel panic, included in the attachment.
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.