This repository has been archived by the owner on Feb 23, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 75
On certain systems, systemd fails to use ttyS0 as Standard Output #130
Labels
Comments
meghadey
pushed a commit
that referenced
this issue
Feb 20, 2019
Commit b12bf16 "luv-test: update standard output for luv" updated the default standard output of LUV to ttyS0 for x86 and ttyAMA0 for ARM architectures. However, after this change it was observed that on some x86 systems, systemd fails to use ttyS0 as Standard Output and the system appears to hang. By reverting the above commit, we no longer see this issue, but we do not see test-suite logs for ARM architecture on the serial console. Hence, selectively revert the above patch for x86 architecture. This patch resolves the issue: #130 Signed-off-by: Megha Dey <megha.dey@linux.intel.com>
meghadey
pushed a commit
that referenced
this issue
Jun 25, 2019
Commit b12bf16 "luv-test: update standard output for luv" updated the default standard output of LUV to ttyS0 for x86 and ttyAMA0 for ARM architectures. However, after this change it was observed that on some x86 systems, systemd fails to use ttyS0 as Standard Output and the system appears to hang. By reverting the above commit, we no longer see this issue, but we do not see test-suite logs for ARM architecture on the serial console. Hence, selectively revert the above patch for x86 architecture. This patch resolves the issue: #130 Signed-off-by: Megha Dey <megha.dey@linux.intel.com>
meghadey
pushed a commit
that referenced
this issue
Jun 25, 2019
Commit b12bf16 "luv-test: update standard output for luv" updated the default standard output of LUV to ttyS0 for x86 and ttyAMA0 for ARM architectures. However, after this change it was observed that on some x86 systems, systemd fails to use ttyS0 as Standard Output and the system appears to hang. By reverting the above commit, we no longer see this issue, but we do not see test-suite logs for ARM architecture on the serial console. Hence, selectively revert the above patch for x86 architecture. This patch resolves the issue: #130 Signed-off-by: Megha Dey <megha.dey@linux.intel.com>
meghadey
pushed a commit
that referenced
this issue
Jun 25, 2019
Commit b12bf16 "luv-test: update standard output for luv" updated the default standard output of LUV to ttyS0 for x86 and ttyAMA0 for ARM architectures. However, after this change it was observed that on some x86 systems, systemd fails to use ttyS0 as Standard Output and the system appears to hang. By reverting the above commit, we no longer see this issue, but we do not see test-suite logs for ARM architecture on the serial console. Hence, selectively revert the above patch for x86 architecture. This patch resolves the issue: #130 Reviewed-By/Tested-By: Naresh Bhat <naresh.bhat at linaro.org> Signed-off-by: Megha Dey <megha.dey@linux.intel.com>
meghadey
pushed a commit
that referenced
this issue
Jun 25, 2019
Commit b12bf16 "luv-test: update standard output for luv" updated the default standard output of LUV to ttyS0 for x86 and ttyAMA0 for ARM architectures. However, after this change it was observed that on some x86 systems, systemd fails to use ttyS0 as Standard Output and the system appears to hang. By reverting the above commit, we no longer see this issue, but we do not see test-suite logs for ARM architecture on the serial console. Hence, selectively revert the above patch for x86 architecture. This patch resolves the issue: #130 Reviewed-By/Tested-By: Naresh Bhat <naresh.bhat at linaro.org> Signed-off-by: Megha Dey <megha.dey@linux.intel.com>
meghadey
pushed a commit
that referenced
this issue
Jun 25, 2019
Commit b12bf16 "luv-test: update standard output for luv" updated the default standard output of LUV to ttyS0 for x86 and ttyAMA0 for ARM architectures. However, after this change it was observed that on some x86 systems, systemd fails to use ttyS0 as Standard Output and the system appears to hang. By reverting the above commit, we no longer see this issue, but we do not see test-suite logs for ARM architecture on the serial console. Hence, selectively revert the above patch for x86 architecture. This patch resolves the issue: #130 Reviewed-By/Tested-By: Naresh Bhat <naresh.bhat at linaro.org> Signed-off-by: Megha Dey <megha.dey@linux.intel.com>
meghadey
pushed a commit
that referenced
this issue
Jun 25, 2019
Commit b12bf16 "luv-test: update standard output for luv" updated the default standard output of LUV to ttyS0 for x86 and ttyAMA0 for ARM architectures. However, after this change it was observed that on some x86 systems, systemd fails to use ttyS0 as Standard Output and the system appears to hang. By reverting the above commit, we no longer see this issue, but we do not see test-suite logs for ARM architecture on the serial console. Hence, selectively revert the above patch for x86 architecture. This patch resolves the issue: #130 Reviewed-By/Tested-By: Naresh Bhat <naresh.bhat at linaro.org> Signed-off-by: Megha Dey <megha.dey@linux.intel.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This is serious because the system appears to hang. The splash screen only shows the status of telemetrics.
After debugging, systemctl status luv-test-manager.service shows
luv-test-manager.service: control process exited, code=exited status=209
According to [1], this means that systemd was unable to setup the file descriptor for stdout.
In a recent patch [2], the StandardOuput is set to tty with TTYPath as ttyS0 for x86. Oddly, this system does have a /dev/ttyS0.
Replacing the StandardOutput with journal+console causes the LUV test manager to print its output on the virtual terminals (tty0) but not the serial console at boot. However, if the LUV test manager is started from the login screen, the output goes to the serial console as expected.
I verified that the the file /sys/classes/tty/console/active has ttyS0 in it.
Thanks and BR,
Ricardo
[1] https://bugzilla.redhat.com/show_bug.cgi?id=737292
[2] b12bf16
The text was updated successfully, but these errors were encountered: