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):
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...
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:
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
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, ,, )
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:
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.