**** BEGIN LOGGING AT Mon Feb 28 02:59:57 2022 Feb 28 03:24:34 rcn-ee: I just looke at their HVAC system deployment using an OSD335x type of chip. Very interesting, i.e. esp. the part w/ networking. Feb 28 03:27:14 side note...I got like 45 paragraphs in w/ photos, code, and descriptions. Google Blogger died on me. Feb 28 03:27:15 Ha. Feb 28 03:28:10 Are you asking me if I yelled at google from my living room? I am shy but not too shy. Sure I did. Yes sir! Feb 28 07:32:16 Hello Together Feb 28 07:32:17 I am new to beaglebone. Feb 28 07:32:17 I bought beaglebone black. I am unbale to SSH to board however I am able to connect board via serial connection. Feb 28 07:32:18 I am using Macbook Pro M1. Feb 28 07:32:18 Can anyone please help? Feb 28 07:32:51 I used "ssh debian@192.168.6.2" Feb 28 07:33:04 I get "ssh: connect to host 192.168.6.2 port 22: Operation timed out" Feb 28 07:39:21 denix Can you please help Feb 28 07:44:48 jkridner Can you please help Feb 28 07:45:00 agraf can you please help? Feb 28 07:45:16 djinni Can you please help? Feb 28 11:50:51 Hi, I was using Beaglebone Black. Ethernet IP address was not correct sometimes after boot. Tried a software solution provided in link https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/ which didn't work in many cases. Anyone faced the same? Is there a solution to this? Feb 28 13:21:21 Kernel 4.14.71-ti-r80 Feb 28 14:56:45 Raajeshwar: what do you mean by "wrong ip address" ? if you're suffering from the ethernet issue the result would be that ethernet doesn't work whatsoever Feb 28 14:57:42 the IP address configured for Ethernet is the one offered by your network's DHCP server, the BBB has no influence over that Feb 28 15:04:54 Wrong IP address means a random IP assigned to eth0. When that happens board couldn't access the internet. When rebooted again, it just fixes it. Also this doesn't happen in all boards. Only few boards behave this way. Changing LAN switch or connecting to a different network didn't work in that device. Just rebooting few times will make it occur. Feb 28 15:21:17 odd Feb 28 15:21:37 if it's fixed by rebooting then it's definitely not an ethernet phy issue Feb 28 15:22:07 those issues require a hard reset (using the button) or power cycle to resolve Feb 28 15:22:27 so it still sounds like a software issue or networking issue to me Feb 28 15:22:46 although I have no explanation of why it would only affect certain boards Feb 28 15:22:50 Oh ok. But only on 2/10 boards we had. Feb 28 15:23:37 they're all running the same debian image? Feb 28 15:23:42 Yes Feb 28 15:23:55 One image flashed in all boards Feb 28 15:25:04 by "random ip address" you mean a link-local 169.254.xxx.xxx address? Feb 28 15:25:17 Yes Feb 28 15:27:28 I guess I'd try monitoring with a packet sniffer to see what's going on? Feb 28 15:28:21 also try to see if the board is reachable via its link-local IPv6 address (fe80::xxxx:xxxx:xxxx) in that state, e.g. using ping6 from another board Feb 28 15:29:09 Ok. We will try it out. Feb 28 15:30:30 just to clarify, when you said "rebooting" you mean using "sudo reboot" ? Feb 28 15:32:19 Yes Feb 28 15:32:32 From terminal we did "sudo reboot" Feb 28 15:32:46 okay yeah, then this definitely isn't related to the ethernet phy issues described by that article you linked Feb 28 15:33:22 those can neither be triggered by reboot nor resolved by it Feb 28 15:34:38 Ok. For sure we didn't do reset or power down the board by unplugging from the supply. We will further test it and post the updates. Feb 28 15:34:53 Thank you. Feb 28 16:12:47 Raajeshwar: have you posted a pastebin of a full dmesg of those boards yet? i didn't seen anything in the scroll back.. Feb 28 16:19:05 No I haven't posted it. Currently I don't have that board. Will post it once I get to the board. I have a working board now which is perfectly fine. After number of reboots it looks good, getting expected IP. Feb 28 16:20:53 can you get in over usb or serial (j1)? Feb 28 16:22:17 Yes, I was able to connect with USB when I see the issue. I was able to see wrong IP in ifconfig. Feb 28 16:23:16 was the Ethernet plugged in before power up? I've seen some weird hotplug problems with systemd-networkd... Are you using connman, network-manager, systemd-networkd or some other networking backend? Feb 28 16:24:11 Yes, board was connected to ethernet before power up. We are using connman. Feb 28 16:28:34 Raajeshwar: please share: journalctl | grep 'cpsw\|eth\|connman' Feb 28 16:28:56 and systemctl status connman Feb 28 16:29:17 expecting something like: https://paste.debian.net/1232527/ Feb 28 16:31:32 Sure, but I don't have the device with issue right now. I will post it as soon as possible. Feb 28 19:30:58 rcn-ee: also, you've seen hotplug problems with systemd-networkd? any details? Feb 28 19:31:50 it's worked very reliably for me in the many years I've used it now Feb 28 19:32:00 yeah... un-plug ethernet, bootup.... plug in ethernet cable... (5.10.x) ethernet doesn't seem to auto come up.. Feb 28 19:33:02 and it's systemd-networkd specific? or did they just break the driver in 5.10 ? e.g. the phy power management bug workaround thingy Feb 28 19:33:27 i don't think it's phy... flashing board right now to help.. Feb 28 19:34:15 have a kernel log and/or "ip addr" output? Feb 28 19:44:29 zmatt: fresh bootup... Ethernet NOT plugged in.. https://paste.debian.net/1232545/ Feb 28 19:44:58 oh and networkctl ? Feb 28 19:45:09 zmatt: and today... it works... https://paste.debian.net/1232546/ Feb 28 19:46:11 works as i want... https://paste.debian.net/1232547/ Feb 28 19:46:18 that first paste looks like what I'd expect for "ethernet not plugged in" though Feb 28 19:46:37 it's administratively up, but has no carrier Feb 28 19:46:49 checks that off my list... random bugs i've been seeing.; ) Feb 28 19:48:27 that sounds unsatisfying if you think there was a bug but it just randomly vanished Feb 28 19:49:09 about as satifying as my "bad" phy board, showed the issue for 2 days last week, but then started working... Feb 28 19:50:02 we have a board here that statistically showed the phy issue fairly regularly, though I haven't verified it still does it Feb 28 19:50:36 (we used it to test hardware workarounds) Feb 28 19:52:18 Well right now, if your booting v5.10.x+ (with TI's new cpsw driver) there is no kernel workaround.. And on that board, the "u-boot" workaround also wasn't working... then magically started working... hard to test patch options when the boards are so random.. Feb 28 19:54:08 we're still on 4.14, so the current software workaround works for the cases where the phy works but has the wrong address, but that still leaves the cases where the phy doesn't work at all which is the part we were trying to find a workaround for Feb 28 19:55:12 the mainline u-boot board code looked like it's supposed to work for both new and old cpsw driver? but obviously still only for the cases where the phy merely has the wrong address (but otherwise still works) Feb 28 19:58:15 i'm also not even sure if the u-boot section is actually being run.. that was the last thing i playing with, dumping printf's around that.. Feb 28 20:03:15 zmatt: there is a phy scan here, but we drop out before with skip_scan, wonder if we can force the driver to "auto"probe say with device tree variable for probe bus... (pre dt)... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/ti/davinci_mdio.c?h=v5.17-rc6#n408 Feb 28 20:04:26 rcn-ee: well, you kinda want this resolved in u-boot anyway (also for things like netboot), so I do think that that having u-boot patch the DT is ultimately the best solution Feb 28 20:05:01 of course on the latest BBB revision you can (and should) just reset the phy until it works properly, but that doesn't help for previous BBB revisions Feb 28 20:05:20 for the newer design, doing the gpio reset in u-boot is also easier.. for some reason phy-reset is a mess on mainline.. Feb 28 20:05:30 it's best we do all fixes in u-boot Feb 28 20:07:35 yeah the phy reset gpio line should only be used for the workaround, not for normal phy resets u-boot or the kernel may want to do afterwards (for some reason... it doesn't seem to have any point other than delaying link up) Feb 28 20:08:19 since using the phy reset gpio on a properly working phy can (afaik) also result in a faulty phy state Feb 28 20:08:31 the older cpsw driver was already slow enough, doing a reset in linux just slows it down more.. Feb 28 20:08:49 I think I actually patched our kernel to eliminate one of the pointless resets Feb 28 20:10:22 yeah I did.... https://github.com/dutchanddutch/bb-kernel/blob/am33x-v4.14/patches/local/0003-WiP-trying-to-achieve-fast-link-up-at-boot.patch Feb 28 20:13:14 that's cool.. and if we fix 'reset' in u-boot, it gives linux a chance to not f**k it up.. Feb 28 20:13:34 well, soft-reset via mdio can't fuck up the phy Feb 28 20:13:51 it just wastes time **** ENDING LOGGING AT Tue Mar 01 02:59:56 2022