Bug 2162741

Summary: MMIO-based serial port does not work during the installation but works later
Product: Red Hat Enterprise Linux 8 Reporter: Carlos Santos <casantos>
Component: kernelAssignee: Doug Ledford <dledford>
kernel sub component: Other QA Contact: Red Hat Kernel QE team <kernel-qe>
Status: CLOSED MIGRATED Docs Contact:
Severity: medium    
Priority: medium CC: dledford, jstancek, knikam
Version: 8.7Keywords: MigratedToJIRA
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-12 17:56:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
transcript of the serial console during the attempt to install over the serial port
none
sosreport generated after installing the system using minitor and keyboard none

Description Carlos Santos 2023-01-20 17:48:47 UTC
Created attachment 1939467 [details]
transcript of the serial console during the attempt to install over the serial port

Description of problem:

Device is a Curtiss-Wright VPX6-196 SBC: https://www.curtisswrightds.com/products/computing/processors/6u-vpx/vpx6-1961

Datasheet: https://www.curtisswrightds.com/sites/default/files/2022-02/VPX6-1961-Intel-Xeon-W-Single-Board-Computer-product-sheet.pdf

The BIOS only supports MMIO-based serial ports.

Attempts to install in text mode over a serial port fail. It is still possible
to install using a monitor an a keyboard. After that, ttyS5 works as expected. 

Version-Release number of selected component (if applicable):

RHEL 8.7 (rhel-8.7-x86_64-dvd.iso dumped to a USB stick)

How reproducible:

Always

Steps to Reproduce:
1. Boot from the RHEL 8.7 installation media using a serial terminal attaced
to the second serial port.

2. At the GRUB prompt, edit the kernel command line to force it to start an
early console on the required I/O address and to use ttyS1 later:

   linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=RHEL-8-7-0-BaseOS-x86_64 console=uart,mmio32,0x6006353000,115200n8 console=ttyS1,115200 inst.text

3. Type Ctrl-X to start

Actual results:

Kernel messages stop being shown after this:

[    0.000000] random: crng done (trusting CPU's manufacturer)
[    0.001000] Console: colour dummy device 80x25

Expected results:

The serial port should become the system console and be used by Anaconda
to perform the installation.

Additional info:

At the installation, the srial ports are mapped to ttyS[0-3], according to the
anaconda log /var/log/anaconda/journal.log:

Jan 01 00:00:43 localhost kernel: dw-apb-uart.1: ttyS0 at MMIO 0x6006354000 (irq = 33, base_baud = 114825) is a 16550A
Jan 01 00:00:43 localhost kernel: dw-apb-uart.2: ttyS1 at MMIO 0x6006353000 (irq = 16, base_baud = 114825) is a 16550A
Jan 01 00:00:43 localhost kernel: dw-apb-uart.3: ttyS2 at MMIO 0x6006352000 (irq = 17, base_baud = 114825) is a 16550A

After the installation, they are mapped to ttyS[4-6]
Dec 31 19:54:33 localhost kernel: dw-apb-uart.1: ttyS4 at MMIO 0x6006354000 (irq = 33, base_baud = 114825) is a 16550A
Dec 31 19:54:33 localhost kernel: dw-apb-uart.2: ttyS5 at MMIO 0x6006353000 (irq = 16, base_baud = 114825) is a 16550A
Dec 31 19:54:33 localhost kernel: dw-apb-uart.3: ttyS6 at MMIO 0x6006352000 (irq = 17, base_baud = 114825) is a 16550A

Using ttyS5 at the installation does not make any difference.

Attaching a transcript of the serial console during the attempt to install over
the serial port.

Attaching an sosreport generated after installing the system using minitor and keyboard.
---------!---------!---------!---------!---------!---------!---------!---------!

Comment 1 Carlos Santos 2023-01-20 17:52:58 UTC
Created attachment 1939468 [details]
sosreport generated after installing the system using minitor and keyboard

Comment 4 Doug Ledford 2023-07-12 16:33:53 UTC
This bug is scheduled for migration to Jira.  When that happens, this bugzilla issue will be permanently closed with the status MIGRATED and all future interaction on this issue will need to happen in the Jira issue.  The new issue will be part of the RHEL project (a project for Jira only issues, which will sync once, then close the bugzilla issue and all future updates will happen in Jira), not part of the RHELPLAN project (which is part of the automated bugzilla->Jira mirroring and which allows ongoing updates to the bugzilla bug and syncs those updates over to Jira).

For making sure you have access to Jira in order to continue accessing this issue, follow one of the appropriate knowledge base articles:

KB0016394 - https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016394
KB0016694 - https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016694
KB0016774 - https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016774

For general issues with Jira, open a ticket with rh-issues

For information specific to using Jira for RHEL issues, contact the RHEL In Jira (RIJ) team at rij-list

Comment 5 Doug Ledford 2023-07-12 17:56:33 UTC
This bug has been migrated to Jira.  All further updates should take place there and the bugzilla bug will now be closed.

https://issues.redhat.com/browse/RHEL-775