Firstly your jsg001@xxxxxxxxxxxxxxxxx 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 _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
