fwiw, I’m seeing what appears to be this same issue on the latest board I’ve bought - occasionally there is no Ethernet connectivity on power-up, a physical power off/on always resolves it…
This is a rev B board, running the latest Debian test image with beta 3.13 kernel, and has happened on both USB and DC power.
Regards,
Jon
Does anyone happen to know if the 3.8 kernel compiled as per these instructions here http://eewiki.net/display/linuxonarm/BeagleBone+Black also contains the fix? I have a root file system already that I want to use but would like to update my kernel to fix this problem.
Thanks.
Sorry, "the fix" is too generic of a term, therefore I can neither
confirm nor deny it. Either way, that 3.8 branch listed is the one
currently used in all debian/ubuntu images being shipped.
Regards,
FWIW I have seen the "PHY problem" repeatedly using the 3.8 kernel, but not yet with the RCN 3.13 kernel.
Regards,
Dave.
I have seen this problem repeatedly by A6 revision hardware, but not with revision A5C hardware (I am running exactly the same software on both).
Noteworthy is that the “PHY problem” only appears when powering the BBB via the headers. Powering via USB does not give any problems.
I tried the following:
-Use the kernel from the v3.8.13-bone40 image
-Change some lines in davinci_mdio.c to hardcode the mask to 0 (“desperately scan all phys”)
Both tries weren’t lucky. It seems to me that the CPU cannot find the PHY chip, because it never powers up.
Well, if it works via USB, but not with the headers. (I didn't check
if the Ethernet can be powered from the headers.)
I'd first double check your power regulation. It's probably dropping
from 5Volts when under load.
Regards,
I'm powering my BBB using P9 pins 1/2 for 0v and 5/6 for +5v, I'm
using the 'real' ethernet connection and it works fine. It has run
with no problems for at least 24 hours, staying connected (ssh) to my
desktop computer.
The 5V is fine (maybe a little spike of 0.8V after 60 ms PS).
However, the 3.3V gives a strange 2-stage powerup cycle. I compared a revision A5C to a revision A6, see plots below.
As can be seen the A5C has a 'normal ’ powerup cycle on the 3.3V, but the A6 a 2-stage powerup cycle. May this cause any problems with PHY?
Where are you looking exactly?
Gerald
I measure 3.3V on P9.3.
USB powering shows the ‘good’ powercycle, 5V via P9.5 shows a ‘bad’ powercycle.
Btw, I seen that in revision A6 and A4 there is an NCP349 chip between VDD_5V and pin 10 of the TPS65217b, which I cant see in revision A5.
I did not use the NCP349 on the BBB. What board are you looking at?
Gerald
After upgrading to the new kernel I setup a script to constantly soft reboot a revision B beaglebone black and have not seen the ethernet lockup once after some 800 consecutive reboots. With the old kernel I did see the ethernet lockup after soft reboots on the same board.
I did however see the libphy: PHY 4a101000.mdio:01 not found message on rebooting many times.
When you say you see the “PHY problem repeatedly” do you mean you see the error messages on boot or have you actually seen the ethernet fail?
Haha, I was looking at the wrong file (BB white A6). Sorry for the trouble; it seems our cape causes this difference between A5C and A6.
A cape. I hate capes. Maybe on the next revision I will just disable all of them!
Thanks!
Gerald
I know our company appreciates the cape support, so thanks for supporting it 
Been watching this thread anxiously for a while. So glad to see a fix was made, but we are using an Ubuntu 12.04 build for ARM (we really wanted to use Ubuntu to be consistent with our other field deployments). Rob, can you point us to the source changes that were made for this issue so that we can patch our kernel or whatever needs to be patched so we can get a fix in?
Not sure my original post got posted, so at risk of double-posting I’m going to post again (sorry).
Gerald, my company loves the Cape support. Sorry, but thank you for supporting it! It has made what we’re doing with the BeagleBone Black capable!
Rob, regarding the OS patch - can you point us to where the source to the patch is? We use Ubuntu 12.04 to be consistent with our other platforms, so we’d like to apply the patch ourselves. We’ve seen this issue a concerning amount of times… in fact, the Ethernet will just drop out, and we have software to detect this and issue a reset and that’s when the PHY is not detected until we completely drop and re-apply power.
Thanks so much everyone for the work so far!
Update. I have now witnessed the problem on RCS’s 3.13.x kernels 
Update #2 FWIW when this occurs I cannot use the Ethernet interface even from uboot. It needs a hard reset to get out of this condition. Dave.
I’m using 3.14.4 kernel (latest stable) - and ‘the fix’ doesn’t seem to have been pushed there - could you give more information about what ‘the fix’ is?