Fresh install of Fedora 32 on a Xilinux Zynq (Trenz Electronics TE0726-03M zynqberry). systemd 245.4-1 has a segmentation fault on boot. Downgrading to 243.8-1 from fedora 31 works as expected.
The relevant syslog error follows: systemd-udevd[1312]: Using default interface naming scheme 'v245'. systemd-udevd[1312]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable. systemd-udevd[1304]: eth0: Worker [1312] processing SEQNUM=968 is taking a long time systemd-udevd[1304]: Worker [1312] terminated by signal 11 (SEGV) systemd-udevd[1304]: eth0: Worker [1312] failed systemd-coredump[1348]: Process 1312 (systemd-udevd) of user 0 dumped core. Stack trace of thread 1312: #0 0x00000000004ace70 builtin_net_setup_link.lto_priv.0 (systemd-udevd + 0x29e70)
Before pursuing this as a possible bug, I would like to ask if anyone recognizes this error or knows of possible causes.
Thanks in advance, jsg
Hi John,
Fresh install of Fedora 32 on a Xilinux Zynq (Trenz Electronics TE0726-03M zynqberry). systemd 245.4-1 has a segmentation fault on boot.
It sounds similar to this bug [1] but I've not looked closely.
Peter
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1831239
Downgrading to 243.8-1 from fedora 31 works as expected.
The relevant syslog error follows: systemd-udevd[1312]: Using default interface naming scheme 'v245'. systemd-udevd[1312]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable. systemd-udevd[1304]: eth0: Worker [1312] processing SEQNUM=968 is taking a long time systemd-udevd[1304]: Worker [1312] terminated by signal 11 (SEGV) systemd-udevd[1304]: eth0: Worker [1312] failed systemd-coredump[1348]: Process 1312 (systemd-udevd) of user 0 dumped core. Stack trace of thread 1312: #0 0x00000000004ace70 builtin_net_setup_link.lto_priv.0 (systemd-udevd + 0x29e70)
Before pursuing this as a possible bug, I would like to ask if anyone recognizes this error or knows of possible causes.
Thanks in advance, jsg _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Thanks Peter. They appear different. I don't get a kernel panic, but rather a segv on a systemd-udevd thread related to eth0 that does not kill systemd-udevd nor create a kernel panic.
After boot, a "udevadm trigger --type=devices --action=add" seems to succeed and bring eth0 up without error.
Restarting systemd-udevd and issuing "udevadm trigger --type=subsystems --action=add" and "udevadm trigger --type=devices --action=add" also succeeds, brings up eth0, and no thread segv.
I can not reproduce the segv after boot and I don't see an easy way to debug systemd-udevd in the middle of booting.
By adding log messages, I can see the problem is in link-config.c. The looping through alternative_names_policy is failing. if I comment out that section of code, the system boots as expected.
Firstly your jsg001@fedoraproject.org bounces, I think that's because you've not agreed to the contributor agreement, so could you resolve that one way or the other.
I don't get a kernel panic, but rather a segv on a systemd-udevd thread related to eth0 that does not kill systemd-udevd nor create a kernel panic.
After boot, a "udevadm trigger --type=devices --action=add" seems to succeed and bring eth0 up without error.
Restarting systemd-udevd and issuing "udevadm trigger --type=subsystems --action=add" and "udevadm trigger --type=devices --action=add" also succeeds, brings up eth0, and no thread segv.
I can not reproduce the segv after boot and I don't see an easy way to debug systemd-udevd in the middle of booting.
Yea, no kidding, I've never had much luck with getting useful debug info out of it.
By adding log messages, I can see the problem is in link-config.c. The looping through alternative_names_policy is failing. if I comment out that section of code, the system boots as expected.
Is that file in systemd? So it shouldn't crash if something fails. I think we have 2 issues here, 1) the issue with the network that's causing the crash 2) the crash.
I think if we report the systemd-udev issue upstream to get that fixed. I suspect the network side of things, if it works once the device has booted, may be due to some module dependency not being properly specified and hence not being pulled into the initrd, we can look at that here to work out the case there.
I don't see a zynqberry in the upstream device tree lists, are you providing a DT?
Peter