As suggested in this discussion i moved to 3.14.1 kernel and everything went well for the first 48 hours. After that i could see that the ETH stopped responding for close to 10 seconds. Then it came back.
Test set up:- I'm using BBB for Data acquisition thru ETH. For testing i have connected BBB and 2 PC in a switch. One PC is running a data acquisition software to collect data from BBB. Another PC is running the software "Total Network Monitor" and it keeps on logging the Network status by pinging to both BBB & the other PC. After 48 Hours :- I could see that the Total Network monitor reported that link to BBB was lost for close to 10 seconds. Is this a known issue ? Is there any fix to this. regards, Jerin On Saturday, 22 November 2014 14:25:03 UTC+5:30, alexschn...@gmail.com wrote: > > But the SW can do that only when the transceiver chip is always in a > "writable" state, which is unfortunately not the case. > > On Saturday, November 22, 2014 1:38:54 AM UTC+1, Gerald wrote: >> >> All the SW has to do itvwrite to the registers and not rely on the >> straps. Hmm I have been saying that for 3+ years now. >> >> Gerald >> >> On Friday, November 21, 2014, <alexschn...@gmail.com> wrote: >> >>> Hi Gerald, >>> >>> I meant "strap values", not connections on the board. As far as I >>> understand it, correct strappings alone cannot always ensure correct bits >>> in the respective registers of the transceiver chip. The power-on and reset >>> timing is also important, and this timing, unlike strappings, is different >>> at least for some revisions. >>> >>> In my experiments, a reset performed with RESET button never resolved >>> the "phy not found" problem. A power-on reset as well as a reset with POWER >>> button helped, but not always. Cannot the transceiver sometimes enter into >>> some unresponsive state, which makes it impossible for the processor to >>> override the strappings? >>> >>> Alex >>> >>> On Thursday, November 20, 2014 9:50:56 PM UTC+1, Gerald wrote: >>>> >>>> If you have what you think are he correct trappings, let me know. They >>>> are the same for all revisions. >>>> >>>> Also, if you reset the board after it is up, the strappings are >>>> overridden by the states on those pins from the processor that override >>>> the >>>> strapping options. >>>> >>>> Gerald >>>> >>>> >>>> On Thu, Nov 20, 2014 at 12:39 PM, <alexschn...@gmail.com> wrote: >>>> >>>>> >>>>> Hello, >>>>> >>>>> This Ethernet trouble also happens with my BeagleBone Black boards, >>>>> quite frequently on Rev C (PCB Rev B6), and very rarely on Rev A6 (PCB >>>>> Rev >>>>> B5). I tried various Linux kernels, including the latest one from here >>>>> <https://eewiki.net/display/linuxonarm/BeagleBone+Black> >>>>> (3.8.13-bone67), however that keeps happening anyway. >>>>> >>>>> I read section 3.7 of the LAN8710A data sheet >>>>> <http://ww1.microchip.com/downloads/en/DeviceDoc/8710a.pdf> >>>>> (Configuration Straps) and I agree with Loren Amelang: the trouble may be >>>>> really caused by incorrect strap values, which depend on voltage levels >>>>> at >>>>> the respective LAN8710A pins during reset. >>>>> >>>>> That assumption is backed by the observation that, whenever the "eth0: >>>>> link not ready" thing happens, either both LEDs of the Ethernet Connector >>>>> are off or only the yellow one (LED2) is off (and the green one is not >>>>> blinking in both cases). Since these LEDs reflect the transceiver mode of >>>>> operation, which is controlled by MODE[2:0] configuration straps, their >>>>> strange behavior may indicate some wrong bit values loaded to MODE[2:0]. >>>>> They are loaded when nRST pin is deasserted, and the timing is critical, >>>>> according to subsection 5.5.3 of that data sheet (Power-On nRST & >>>>> Configuration Strap Timing). >>>>> >>>>> Also, according to the subsection mentioned above, the time interval >>>>> between when external power supplies reach 80% and nRST pin is deasserted >>>>> must be no less than 25 ms. Without the capacitor C24 on the board, that >>>>> time is around 20 ms, I measured that. So, removing C24 does not seem to >>>>> be >>>>> safe. >>>>> >>>>> Alex >>>>> >>>>> >>>>> >>>>> >>>>> On Wednesday, November 5, 2014 7:03:21 AM UTC+1, Jerin George wrote: >>>>>> >>>>>> HI Andrew & John, >>>>>> >>>>>> Thank you for your reply. I guess that leaves me with no choice but >>>>>> to tweak the hardware & also update the kernel to the latest version by >>>>>> Robert. >>>>>> Hopefully that will fix the issue for ever. >>>>>> I will keep you posted on the status. >>>>>> >>>>>> regards, >>>>>> Jerin >>>>>> >>>>>> On Wednesday, 5 November 2014 01:23:28 UTC+5:30, john3909 wrote: >>>>>>> >>>>>>> >>>>>>> From: Andrew Glen <andrewt...@gmail.com> >>>>>>> Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com> >>>>>>> Date: Monday, November 3, 2014 at 11:36 PM >>>>>>> To: "beagl...@googlegroups.com" <beagl...@googlegroups.com> >>>>>>> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not >>>>>>> Detected on Boot. >>>>>>> >>>>>>> Yes, and reading the thread even more fully you'll find my report of >>>>>>> running thousands of automated test restarts with these parts removed, >>>>>>> with >>>>>>> a 100% success rate. >>>>>>> >>>>>>> We use these boards a lot, running 24-7 in this configuration, and >>>>>>> have had zero hardware faults. With any luck we have nearly exhausted >>>>>>> Murphy's law with our software. >>>>>>> >>>>>>> Hi Andrew, >>>>>>> >>>>>>> I accept that you have done these tests, but removing test two >>>>>>> capacitors from the reset line means the device will come out of reset >>>>>>> before the power supply has stabilized and without a capacitor, the >>>>>>> reset >>>>>>> switch will bounce several times. That is not a good idea. Perhaps you >>>>>>> are >>>>>>> just lucky given your setup, but removing C24 and C30 is a bad idea. >>>>>>> Making >>>>>>> these capacitors smaller may fix your problem but I suggest that you do >>>>>>> have something there to delay the reset line. >>>>>>> >>>>>>> Regards, >>>>>>> John >>>>>>> >>>>>>> Andrew. >>>>>>> On 4/11/2014 7:26 PM, "John Syn" <john...@gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> From: Andrew Glen <andrewt...@gmail.com> >>>>>>>> Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com> >>>>>>>> Date: Monday, November 3, 2014 at 9:42 PM >>>>>>>> To: "beagl...@googlegroups.com" <beagl...@googlegroups.com> >>>>>>>> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not >>>>>>>> Detected on Boot. >>>>>>>> >>>>>>>> As far as I know, and as already documented in this thread, the >>>>>>>> only reliable fix is to remove C24 and C30. >>>>>>>> >>>>>>>> If you read the full thread, Gerald say that if you remove these >>>>>>>> capacitors, the board may not start at all. >>>>>>>> >>>>>>>> Regards, >>>>>>>> John >>>>>>>> >>>>>>>> On 4/11/2014 5:40 PM, "Jerin George" <george...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> I am using a BBB Rev C with latest Angstrom image and i have seen >>>>>>>>> this issue with eth not getting detected at boot up. This came at the >>>>>>>>> last >>>>>>>>> stages of my project delivery. How can this be corrected. Does moving >>>>>>>>> to >>>>>>>>> the latest debian image solves this issue ? >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> Jerin George >>>>>>>>> >>>>>>>>> On Saturday, 26 July 2014 04:31:42 UTC+5:30, cmid...@gmail.com >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> They phymask comes from a hardware register read by the >>>>>>>>>> davinci_mdio driver, which gets passed to the linux phy libraries. >>>>>>>>>> The >>>>>>>>>> problem is that the cpsw driver gets the value from device tree, >>>>>>>>>> which is >>>>>>>>>> hardcoded to address 0. Usually the values are the same (address 0), >>>>>>>>>> but >>>>>>>>>> sometimes the phy gets registered to a different address, usually in >>>>>>>>>> my >>>>>>>>>> case address 2. You calculate the address using the phymask. If you >>>>>>>>>> changed >>>>>>>>>> the phymask than, you pointing back to address 0, so that wouldn't >>>>>>>>>> help you. >>>>>>>>>> >>>>>>>>>> I rebuilt the dtb file. >>>>>>>>>> >>>>>>>>>> On Thursday, July 24, 2014 4:10:18 PM UTC-4, Loren Amelang wrote: >>>>>>>>>>> >>>>>>>>>>> On Wednesday, July 23, 2014 3:54:00 PM UTC-7, cmid...@gmail.com >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> The davinci mdio driver should report a phymask and that value >>>>>>>>>>>> is used to update the device tree. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Back when I had this problem I tried hard to find out where the >>>>>>>>>>> phymask comes from, and never succeeded. At that time people who >>>>>>>>>>> received a >>>>>>>>>>> phymask of fffffffe booted successfully, those with fffffffb >>>>>>>>>>> failed. Do you >>>>>>>>>>> know where the mask is found and how to change it? >>>>>>>>>>> >>>>>>>>>>> I also remove the second phy slave from the device tree. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> That seems like a great idea, if only to stop all the useless >>>>>>>>>>> messages about it never being found. Can that be done in the >>>>>>>>>>> uEnv.txt, like >>>>>>>>>>> when you disable HDMI, or do you have to rebuild the device tree >>>>>>>>>>> binary? >>>>>>>>>>> Would setting the phymask to ffffffff accomplish the same thing? >>>>>>>>>>> >>>>>>>>>>> Loren >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> For more options, visit http://beagleboard.org/discuss >>>>>>>>> --- >>>>>>>>> You received this message because you are subscribed to a topic in >>>>>>>>> the Google Groups "BeagleBoard" group. >>>>>>>>> To unsubscribe from this topic, visit https://groups.google.com/d/ >>>>>>>>> topic/beagleboard/9mctrG26Mc8/unsubscribe. >>>>>>>>> To unsubscribe from this group and all its topics, send an email >>>>>>>>> to beagleboard...@googlegroups.com. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> -- >>>>>>>> For more options, visit http://beagleboard.org/discuss >>>>>>>> --- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "BeagleBoard" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to beagleboard...@googlegroups.com. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>>> -- >>>>>>>> For more options, visit http://beagleboard.org/discuss >>>>>>>> --- >>>>>>>> You received this message because you are subscribed to a topic in >>>>>>>> the Google Groups "BeagleBoard" group. >>>>>>>> To unsubscribe from this topic, visit https://groups.google.com/d/ >>>>>>>> topic/beagleboard/9mctrG26Mc8/unsubscribe. >>>>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>>>> beagleboard...@googlegroups.com. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> -- >>>>>>> For more options, visit http://beagleboard.org/discuss >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "BeagleBoard" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to beagleboard...@googlegroups.com. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "BeagleBoard" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to beagleboard...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Gerald >>>> >>>> ger...@beagleboard.org >>>> http://beagleboard.org/ >>>> http://circuitco.com/support/ >>>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "BeagleBoard" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to beagleboard+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> -- >> Gerald >> >> ger...@beagleboard.org >> http://beagleboard.org/ >> http://circuitco.com/support/ >> >> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
