[systemd-devel] systemd doesn't see ttyPS0 devices from udev
ZhouPeng
zhoupengwork01 at 163.com
Sun Sep 27 06:09:55 UTC 2020
Thanks all,
At 2020-09-24 00:25:44, "Michael Olbrich" <m.olbrich at pengutronix.de> wrote:
>Hi,
>
>On Wed, Sep 23, 2020 at 04:58:57PM +0800, ZhouPeng wrote:
>> I find that boot with the 'rescue' option, then exit 'rescue' mode, then
>> I can login to the ttyPS0, as below
>
>You're using a custom kernel, right? Please check the README in the systemd
>source tree. Specifically the kernel config options.
Yes, build from linux 4.18 source, and custom by select kernel build options.
>From what I remember, what you describe happens when CONFIG_FHANDLE is
>disabled in the kernel.
Compared with the https://github.com/systemd/systemd/blob/master/README
In my .config, Kernel Config Options are seted as below:
CONFIG_FHANDLE=y
CONFIG_DEVTMPFS=y
CONFIG_CGROUPS=y
CONFIG_INOTIFY_USER=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EPOLL=y
CONFIG_NET=y
CONFIG_SYSFS=y
CONFIG_PROC_FS=y
# CONFIG_SYSFS_DEPRECATED is not set // *** I set CONFIG_SYSFS_DEPRECATED=n in the .config, Kconfig system will override to get “# CONFIG_SYSFS_DEPRECATED is not set”.
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_FW_LOADER_USER_HELPER is not set //*** I set CONFIG_FW_LOADER_USER_HELPER=n in the .config, Kconfig system will override to get “# CONFIG_FW_LOADER_USER_HELPER is not set”.
# no CONFIG_DMIID=y //*** I set CONFIG_DMIID=y in the .config, but Kconfig system will override to get it removed. I don't known if this will take side effects. "Some udev rules and virtualization detection relies on it"
CONFIG_BLK_DEV_BSG=y
CONFIG_NET_NS=y
CONFIG_USER_NS=y
Best Wishes,
Peng Zhou
>Regards,
>Michael
>
>
>> bash-4.4# exit // *here exit rescue mode*
>> exit
>> Reloading system manager configuration
>> Starting default target
>> [ 1708.910000] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>> [ 1712.080000] macb e000b000.ethernet eth0: link up (100/Full)
>> [ 1712.080000] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>> ...
>> Build date: 2019-08-22 21:56
>>
>>
>> Kernel 4.18.0-14480-gc4490f2dabc1 on an riscv64 (ttyPS0)
>> ...
>> stage4 login: root
>> Password:
>> [root at stage4 ~]#
>>
>>
>>
>>
>> But how boot directly normally.
>> Thanks all,
>> At 2020-09-23 16:37:48, "ZhouPeng" <zhoupengwork01 at 163.com> wrote:
>> >Thank you very much. ' udevadm info -a /dev/ttyPS0' output:
>> >
>> >
>> >bash-4.4# udevadm info -a /dev/ttyPS0
>> >
>> >Udevadm info starts with the device specified by the devpath and then
>> >walks up the chain of parent devices. It prints for every device
>> >found, all possible attributes in the udev rules key format.
>> >A rule to match, can be composed by the attributes of the device
>> >and the attributes from one single parent device.
>> >
>> > looking at device '/devices/platform/soc/e0000000.serial/tty/ttyPS0':
>> > KERNEL=="ttyPS0"
>> > SUBSYSTEM=="tty"
>> > DRIVER==""
>> > ATTR{close_delay}=="50"
>> > ATTR{closing_wait}=="3000"
>> > ATTR{custom_divisor}=="0"
>> > ATTR{flags}=="0x10000000"
>> > ATTR{io_type}=="3"
>> > ATTR{iomem_base}=="0xE0000000"
>> > ATTR{iomem_reg_shift}=="0"
>> > ATTR{irq}=="2"
>> > ATTR{line}=="0"
>> > ATTR{port}=="0x0"
>> > ATTR{type}=="98"
>> > ATTR{uartclk}=="100000000"
>> > ATTR{xmit_fifo_size}=="64"
>> >
>> > looking at parent device '/devices/platform/soc/e0000000.serial':
>> > KERNELS=="e0000000.serial"
>> > SUBSYSTEMS=="platform"
>> > DRIVERS=="xuartps"
>> > ATTRS{driver_override}=="(null)"
>> >
>> > looking at parent device '/devices/platform/soc':
>> > KERNELS=="soc"
>> > SUBSYSTEMS=="platform"
>> > DRIVERS==""
>> > ATTRS{driver_override}=="(null)"
>> >
>> > looking at parent device '/devices/platform':
>> > KERNELS=="platform"
>> > SUBSYSTEMS==""
>> > DRIVERS==""
>> >bash-4.4# ls /dev/ttyPS0 -lh
>> >crw-rw---- 1 root dialout 254, 0 Jan 28 16:05 /dev/ttyPS0
>> >
>> >
>> >Thanks,
>> >
>> >On Wed, Sep 23, 2020, 15:34，"Mantas Mikulėnas" <grawity at gmail.com> wrote:
>> >
>> >
>> >On Wed, Sep 23, 2020, 09:21 ZhouPeng <zhoupengwork01 at 163.com> wrote:
>> >
>> >
>> >
>> >Thank you very much for you great suggestions.
>> >
>> >
>> >
>> >I chroot the rootfs and tried to the 3 methods in '/usr/lib/udev/rules.d' respectively:
>> >
>> >
>> >
>> >try 1) add a line of ACTION!="remove", KERNEL=="ttyPS0", TAG+="systemd" below the line of "ACTION=="remove", GOTO="systemd_end"" in file 99-systemd.rules
>> >
>> >try 2) add a line of ACTION!="remove", KERNEL=="ttyPS0", NAME="ttyPS0", TAG+="systemd" below the line of "ACTION=="remove", GOTO="systemd_end"" in file 99-systemd.rules
>> >
>> >try 3) replace the line "SUBSYSTEM=="tty", KERNEL=="tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*|3270/tty[0-9]*", TAG+="systemd" with "SUBSYSTEM=="tty", KERNEL=="ttyPS[0-9]|tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*|3270/tty[0-9]*", TAG+="systemd"", in file 99-systemd.rules.
>> >
>> >
>> >
>> >At least the 1st one *should* have worked, though NAME= seems wrong in the 2nd one...
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >At the same time, I replace the line of "KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="dialout"" with "KERNEL=="ttyPS[0-9]|tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="dialout"".
>> >
>> >
>> >
>> >This line is irrelevant, since TAG+="systemd" is the important part – groups and modes shouldn't be the problem.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >But they didn't take any effect.
>> >
>> >
>> >
>> >Then at the same time, I do
>> >
>> >cp /usr/lib/systemd/system/serial-getty at .service /etc/systemd/system/serial-getty at ttyPS0.service
>> >
>> >Edit /etc/systemd/system/serial-getty\@ttyPS0.service: replace "ExecStart=-/sbin/agetty --keep-baud 115200,38400,9600 %I $TERM" with "ExecStart=-/sbin/agetty --keep-baud 115200 %I $TERM"
>> >
>> >ln -s /etc/systemd/system/serial-getty at ttyPS0.service /etc/systemd/system/getty.target.wants/
>> >
>> >
>> >
>> >But there was still no effect. There is still boot failure logs like:
>> >
>> >[ *] (3 of 3) a start job is running for dev-ttyPS0.device (41s / 1min 30s)// **here**
>> >
>> >...
>> >
>> > [ TIME ] Timed out waiting for device dev-ttyPS0.device. // **here**
>> >
>> >...
>> >
>> >
>> >
>> >Yeah, the baudrate won't change anything if systemd doesn't even see the device in the first place. It doesn't even get to the point of launching agetty.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >By the way, Do I need to add some configuration to tiger executing something like 'mknod /dev/ttyPS0 c 248 0' for systemd or udev pls? If needed, where is the proper place to add this action pls?
>> >
>> >
>> >
>> >No. The kernel automatically creates device nodes (as long as /dev has a "devtmpfs" mounted); udev only applies modes/symlinks. The problem here is that udev doesn't properly inform systemd about the new device.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >>What does "udevadm info -a /dev/ttyPS0" output?
>> >
>> >I can not get a console from ttyPS0, so I can not run "udevadm info -a /dev/ttyPS0" in the target(xilinx pynq) board.
>> >
>> >
>> >
>> >Try booting with the 'rescue' option, this should directly create a root login prompt on the kernel console.
>> >
>> >
>> >
>> >
>> >
>> >Alternatively, try creating a simple .service that runs this command, then you'll find its output in the journal or in the boot console (depending on what StandardOutput= you set).
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >Thanks all,
>> >
>> >At 2020-09-22 20:34:15, "Andrei Borzenkov" <arvidjaar at gmail.com> wrote:
>> >
>> >>On Tue, Sep 22, 2020 at 2:53 PM Mantas Mikulėnas <grawity at gmail.com> wrote:
>> >
>> >>>
>> >
>> >>> On Tue, Sep 22, 2020 at 1:46 PM Andrei Borzenkov <arvidjaar at gmail.com> wrote:
>> >
>> >>>>
>> >
>> >>>> On Tue, Sep 22, 2020 at 1:35 PM ZhouPeng <zhoupengwork01 at 163.com> wrote:
>> >
>> >>>> >
>> >
>> >>>> > Hi all,
>> >
>> >>>> >
>> >
>> >>>> > When I use Fedora image as rootfs on Xilinx PYNQ-Z2, I encountered the issue when use the /dev/ttyPS0.
>> >
>> >>>> > I think the issue is because systemd and udev on fedora can didn't detect ttyPS0 properly. Do I need to install any other package or do some special configuration?
>> >
>> >>>> >
>> >
>> >>>> > **systemd version the issue has been seen with**
>> >
>> >>>> > udevadm --version
>> >
>> >>>> > 237
>> >
>> >>>> > systemd-udev.riscv64 237-1.0.riscv64.fc28
>> >
>> >>>> >
>> >
>> >>>> >
>> >
>> >>>> > **Unexpected behaviour you saw**
>> >
>> >>>> > We can see ttyPS0 boots ok in the kernel boot period:
>> >
>> >>>> > [ 0.180000] console [ttyPS0] enabledat MMIO 0xe0000000 (irq = 2, base_baud = 6250000) is a xuartps
>> >
>> >>>> > [ 0.180000] console [ttyPS0] enabled
>> >
>> >>>> >
>> >
>> >>>> > But, when boot into systemd, it failed on dev ttyPS0:
>> >
>> >>>> > [ TIME ] Timed out waiting for device dev-ttyPS0.device. // **here**
>> >
>> >>>>
>> >
>> >>>> systemd only monitors for devices with "sysemd" tag. Tags are assigned
>> >
>> >>>> by udev rules. You should add rule to assign tag to ttyPS0. I have no
>> >
>> >>>> idea what it is, but something like
>> >
>> >>>>
>> >
>> >>>> ACTION!="remove", KERNEL=="ttyPS0", TAG+="systemd"Mantas
>> >
>> >>>>
>> >
>> >>>> should do it. Whether this should go upstream depends on how common
>> >
>> >>>> this device is.
>> >
>> >>>
>> >
>> >>>
>> >
>> >>> Well yes, but that should have been already covered by the existing upstream rules:
>> >
>> >>>
>> >
>> >>> 99-systemd.rules:12:SUBSYSTEM=="tty", KERNEL=="tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*|3270/tty[0-9]*", TAG+="systemd"
>> >
>> >>>
>> >
>> >>
>> >
>> >>Are you sure ttyPS0 has the "tty" subsystem?
>> >
>> >
>
>> _______________________________________________
>> systemd-devel mailing list
>> systemd-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
>--
>Pengutronix e.K. | |
>Steuerwalder Str. 21 | http://www.pengutronix.de/ |
>31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
More information about the systemd-devel
mailing list