Bug 1531140 - no console output with acpi on mustang (Warning: unable to open an initial console.)
Summary: no console output with acpi on mustang (Warning: unable to open an initial co...
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: aarch64
OS: Linux
Target Milestone: ---
Assignee: Peter Robinson
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: ARMTracker F28FinalFreezeException
TreeView+ depends on / blocked
Reported: 2018-01-04 16:23 UTC by Paul Whalen
Modified: 2018-04-25 00:05 UTC (History)
20 users (show)

Fixed In Version: kernel-4.16.3-301.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-04-25 00:05:01 UTC
Type: Bug

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

Description Paul Whalen 2018-01-04 16:23:18 UTC
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 16:24:06 UTC
Created attachment 1377020 [details]
Mustang boot with acpi

Comment 2 Mark Salter 2018-01-04 18:32:47 UTC
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 19:24:00 UTC
Iyappan: can you provide any assistance around firmware?

Comment 4 Peter Robinson 2018-04-19 19:48:40 UTC
Mark: is the fix to revert the change or is there another patch?

Comment 5 Mark Salter 2018-04-19 20:51:37 UTC
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-20 03:41:41 UTC
Let's see how this goes:


Comment 7 Peter Robinson 2018-04-23 16:57:57 UTC
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 16:58:19 UTC
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 16:59:44 UTC
Tested on mustang with acpi=force

Comment 10 Adam Williamson 2018-04-24 01:10:19 UTC
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 22:27:40 UTC
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-25 00:05:01 UTC
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.