I burned image am335x-debian-11.8-minimal-armhf-2023-10-07-2gb.img then I replace the kernel with my own, after sometime reboot, I found the eth0 was broken. I attach the full log here. and I found issue log as
[ 25.939430] cpsw 4a100000.ethernet: initializing cpsw version 1.12 (0)
[ OK ] Finished Coldplug All udev Devices.
[ 25.975823] cpsw 4a100000.ethernet: phy "/ocp/interconnect@4a000000/segment@0/target-module@100000/ethernet@0/mdio@1000/ethernet-phy@0" not found on slave 0
Starting Helper to synchronize boot up for ifupdown...
[ OK ] Finished Helper to synchronize boot up for ifupdown.
I wonder how could this happen??? any help will be appreciated.
net_issue.txt (49.0 KB)
It depends on what you did. That is the reason why it takes a very large block of time to move up to another version of kernel. For best results, run the entire RCN image package without your kernel modifications. It has been tested and patches for issues applied.
When you reboot,
post:
$pstree
when I first use the modified kernel,I can boot success with eth0 work properly。and then I migrate the img from sdcard to emmc,it’s ok both But after I boot it yesterday ,I found the eth0 was broken. I modified kernel just with some usb gadget configs different.
and this is my pstree
red@BeagleBone:~$ pstree
systemd─┬─agetty
├─avahi-daemon───avahi-daemon
├─cron
├─dbus-daemon
├─login───bash───pstree
├─rsyslogd───3*[{rsyslogd}]
├─sshd
├─systemd───(sd-pam)
├─systemd-journal
├─systemd-logind
├─systemd-network
├─systemd-resolve
├─systemd-timesyn
├─systemd-udevd
└─wpa_supplicant
It is hard to even guess at that. When it goes down again nmap it from another machine and see if still pings back. If it pings back your config might need some work.
Also, check the systemctl status for your networking and make sure it is still active.
I found a curious situation, I modified /boot/uEnv.txt with the uname_r to original value 5.10.168-ti-r72
.Then reboot bbb, the eth0 can work properly. Then I modified uname_r to my kernel version 5.10.168+
and reboot bbb again, the eth0 can work properly too. 
root@BeagleBone:~# head /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
#uname_r=5.10.168-ti-r72
uname_r=5.10.168+
#uuid=
#dtb=
###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
I wonder how could this happen ???
1 Like
It could also be your networking equipment…
You might have a some one trying to breach your system and they broke it. That is how they force you to reboot so they can load code. Who really knows, I can say that we have not had any problems with the networking on any of the BB products.
Main thing is you are up and running again.