Firstly your jsg001(a)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