[opensuse-arm] systemd waiting on dev-ttySAC3.device
Hello, On Exynos5 devices I've seen the following problem with Factory rootfs. For example, using upstream v3.14 plus a .dts patch with exynos_defconfig (devtmpfs) on Arndale Octa: [ 10.900000] systemd[1]: Expecting device dev-ttySAC3.device... Expecting device dev-ttySAC3.device... [...] [ TIME ] Timed out waiting for device dev-ttySAC3.device. [DEPEND] Dependency failed for Serial Getty on ttySAC3. systemd proceeds printing to console=ttySAC3,115200n8 until reaching target Graphical Interface, but I do not get a login prompt on serial. The YaST firstboot worked on first run, too. No HDMI output, and network not blinking/lit. Booting is currently broken on 3.15.0-rc2-00205-g9a60ee1, and we do not have a building kernel-exynos package, therefore vanilla 3.14 plus http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/a... Initially I had seen this issue on a downstream kernel 3.4.x on my ODROID-XU with s/ttySAC3/ttySAC2/g. There, I was able to log in via ssh and confirm that /dev/ttySAC2 was in fact present. Any suggestions how to debug what is going wrong there? Thanks, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 26.04.2014 18:52, schrieb Andreas Färber:
[ 10.900000] systemd[1]: Expecting device dev-ttySAC3.device... Expecting device dev-ttySAC3.device... [...] [ TIME ] Timed out waiting for device dev-ttySAC3.device. [DEPEND] Dependency failed for Serial Getty on ttySAC3.
I've now encountered this phenomenon on yet another board, the Vybrid based armStoneA5 with downstream 3.0.15 kernel. Running `yast services` via ssh, selecting serial-getty@ttymxc1.service and invoking "Start/stop" followed by "OK" temporarily fixes serial login until reboot, whereas a simple `systemctl restart serial-getty@ttymxc1.service` times out as before. No such problems on my IFC6410 (APQ8064 based) with ttyHSL0 and same Factory. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 27.04.2014 um 08:16 schrieb Andreas Färber <afaerber@suse.de>:
Am 26.04.2014 18:52, schrieb Andreas Färber:
[ 10.900000] systemd[1]: Expecting device dev-ttySAC3.device... Expecting device dev-ttySAC3.device... [...] [ TIME ] Timed out waiting for device dev-ttySAC3.device. [DEPEND] Dependency failed for Serial Getty on ttySAC3.
I've now encountered this phenomenon on yet another board, the Vybrid based armStoneA5 with downstream 3.0.15 kernel.
Running `yast services` via ssh, selecting serial-getty@ttymxc1.service and invoking "Start/stop" followed by "OK" temporarily fixes serial login until reboot, whereas a simple `systemctl restart serial-getty@ttymxc1.service` times out as before.
No such problems on my IFC6410 (APQ8064 based) with ttyHSL0 and same Factory.
Thomas, do you have an idea what's happening here? Alex
Andreas
-- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, On Sun, 27 Apr 2014, Alexander Graf wrote:
Am 27.04.2014 um 08:16 schrieb Andreas Färber <afaerber@suse.de>:
Am 26.04.2014 18:52, schrieb Andreas Färber:
[ 10.900000] systemd[1]: Expecting device dev-ttySAC3.device... Expecting device dev-ttySAC3.device... [...] [ TIME ] Timed out waiting for device dev-ttySAC3.device. [DEPEND] Dependency failed for Serial Getty on ttySAC3.
I've now encountered this phenomenon on yet another board, the Vybrid based armStoneA5 with downstream 3.0.15 kernel.
Running `yast services` via ssh, selecting serial-getty@ttymxc1.service and invoking "Start/stop" followed by "OK" temporarily fixes serial login until reboot, whereas a simple `systemctl restart serial-getty@ttymxc1.service` times out as before.
No such problems on my IFC6410 (APQ8064 based) with ttyHSL0 and same Factory.
Thomas, do you have an idea what's happening here?
The above message suggests that the device ttySAC3 is not present. What serial device name has been specified on the kernel command line? Only this one will be set up automatically. Otherwise, you will need to configure serial-getty@.service manually, see: http://0pointer.de/blog/projects/serial-console.html section: Serial Terminals for details. If ttymxc1 works in the running system but not after reboot, maybe the name/number of the serial device has changed? Regards Thomas
Hi, Am 28.04.2014 09:17, schrieb Thomas Blume:
On Sun, 27 Apr 2014, Alexander Graf wrote:
Am 27.04.2014 um 08:16 schrieb Andreas Färber <afaerber@suse.de>:
Am 26.04.2014 18:52, schrieb Andreas Färber:
[ 10.900000] systemd[1]: Expecting device dev-ttySAC3.device... Expecting device dev-ttySAC3.device... [...] [ TIME ] Timed out waiting for device dev-ttySAC3.device. [DEPEND] Dependency failed for Serial Getty on ttySAC3.
I've now encountered this phenomenon on yet another board, the Vybrid based armStoneA5 with downstream 3.0.15 kernel.
Running `yast services` via ssh, selecting serial-getty@ttymxc1.service and invoking "Start/stop" followed by "OK" temporarily fixes serial login until reboot, whereas a simple `systemctl restart serial-getty@ttymxc1.service` times out as before.
No such problems on my IFC6410 (APQ8064 based) with ttyHSL0 and same Factory.
Thomas, do you have an idea what's happening here?
The above message suggests that the device ttySAC3 is not present. What serial device name has been specified on the kernel command line? Only this one will be set up automatically. Otherwise, you will need to configure serial-getty@.service manually, see:
http://0pointer.de/blog/projects/serial-console.html
section: Serial Terminals
for details.
If ttymxc1 works in the running system but not after reboot, maybe the name/number of the serial device has changed?
I'm attaching my original message for your convenience. The device is there at ssh login time, and yet systemctl-restart'ing the service at that time still times out, not finding it. So it seems that systemd is caching things or not getting file system change notifications? How do these dev-foo.device thingies get created, and can I inspect them through some command or in some log? What exactly does YaST do differently when I ask to start the service there? I've seen a similar timeout issue once I assigned a mount point /boot to a partition residing on an SD card (/dev/mmcblk0p1), dropping me into the dracut rescue shell after timeout. Not using an initrd, this was at a point where /dev/mmcblk0p2 was being used as root already. So there must be a mismatch between /dev devtmpfs and systemd's view of it. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Hi Andreas, On Mon, 28 Apr 2014, Andreas Färber wrote:
I'm attaching my original message for your convenience. The device is there at ssh login time, and yet systemctl-restart'ing the service at that time still times out, not finding it. So it seems that systemd is caching things or not getting file system change notifications? How do these dev-foo.device thingies get created, and can I inspect them through some command or in some log?
What exactly does YaST do differently when I ask to start the service there?
Hm, I'm not really sure about the difference when activating the service via YaST or systemctl. The getty services file is generated at system boot by the systemd-getty-generator. You should find the service file in /usr/lib/systemd/system/ It contains a parameter configured as: TTYPath=/dev/%I %I is the unescaped instance name, e.g. the string between the "@" character %and the suffix of the unit name. Maybe something is wrong with parsing this name. Still, this should be the same behaviour from within YaST: it would be good if I could look directly on such a system. Is it possible to get remote access to a machine where you can see this? Can you open a bug report?
I've seen a similar timeout issue once I assigned a mount point /boot to a partition residing on an SD card (/dev/mmcblk0p1), dropping me into the dracut rescue shell after timeout. Not using an initrd, this was at a point where /dev/mmcblk0p2 was being used as root already. So there must be a mismatch between /dev devtmpfs and systemd's view of it.
Device node creation is normally done via udev inside the initrd. Not sure what happens if you don't have one. When the udev device generation runs after system root is mounted, you might have a race between the mount and the udev services. Still, not sure wheter this is the same issue. Did the mount work in the running system? Regards Thomas
participants (3)
-
Alexander Graf -
Andreas Färber -
Thomas Blume