Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1531140 - no console output with acpi on mustang (Warning: unable to open an initial console.)
no console output with acpi on mustang (Warning: unable to open an initial co...
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
aarch64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Robinson
Fedora Extras Quality Assurance
Depends On:
Blocks: ARMTracker F28FinalFreezeException
  Show dependency treegraph
Reported: 2018-01-04 11:23 EST by Paul Whalen
Modified: 2018-04-24 20:05 EDT (History)
20 users (show)

See Also:
Fixed In Version: kernel-4.16.3-301.fc28
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2018-04-24 20:05:01 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Mustang boot with acpi (47.77 KB, text/plain)
2018-01-04 11:24 EST, Paul Whalen
no flags Details

  None (edit)
Description Paul Whalen 2018-01-04 11:23:18 EST
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):

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.
Comment 1 Paul Whalen 2018-01-04 11:24 EST
Created attachment 1377020 [details]
Mustang boot with acpi
Comment 2 Mark Salter 2018-01-04 13:32:47 EST
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, ,, )

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.
Comment 3 Peter Robinson 2018-01-20 14:24:00 EST
Iyappan: can you provide any assistance around firmware?
Comment 4 Peter Robinson 2018-04-19 15:48:40 EDT
Mark: is the fix to revert the change or is there another patch?
Comment 5 Mark Salter 2018-04-19 16:51:37 EDT
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.
Comment 6 Mark Salter 2018-04-19 23:41:41 EDT
Let's see how this goes:

Comment 7 Peter Robinson 2018-04-23 12:57:57 EDT
Fixed pushed to rawhide (will be in 4.17rc2 build) and the next 4.16 build post 4.16.3-300
Comment 8 Fedora Blocker Bugs Application 2018-04-23 12:58:19 EDT
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.
Comment 9 Peter Robinson 2018-04-23 12:59:44 EDT
Tested on mustang with acpi=force
Comment 10 Adam Williamson 2018-04-23 21:10:19 EDT
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.
Comment 11 Fedora Update System 2018-04-24 18:27:40 EDT
kernel-4.16.3-301.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-b921ff4b1e
Comment 12 Fedora Update System 2018-04-24 20:05:01 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.