LAN/NIC problem

[MarkHaysHarris777]

This is ( one ) of the reasons for collecting the data on the POLL.

my serial that works: 410640133576

my serial that no work: 410640138448

I got my boards about three or four weeks apart. They are dated the same. Physically they have differences in the eth0 field of resistors and caps and the board that does not work is covered in cold solder joints.

I am making high quality micro graphs of each board and will post when they are ready.

edit: PS please feel free to post micro-graphs of your board to the POLL data collection ; thanks !

[tllim]

This is ( one ) of the reasons for collecting the data on the POLL.

my serial that works:  410640133576

my serial that no work:  410640138448

I got my boards about three or four weeks apart.  They are dated the same. Physically they have differences in the eth0 field of resistors and caps and the board that does not work is covered in cold solder joints.

I am making high quality micro graphs of each board and will post when they are ready.

edit:  PS   please feel free to post micro-graphs of your board to the POLL data collection ;  thanks !  

Hi Marcus,

Interest on your finding.

... TL

[pfeerick]

Until we know for *certain* what is the cause(s) of this issue (GbE not working), we shouldn't make any statements ruling anything out. The reason that we are getting off track here at times might be due to something very simple - there are multiple possible points of failure. Anything ranging from the input power (voltage and ripple), poor soldering on the connections, different PHY chips, cabling, network environment, software configuration could be responsible. And it could be just one single factor in somes cases, or any combination, or something else I haven't mentioned.

Different networking environments can also trigger completely failures (I don't go on to talk about the Wireless N router that I had which worked fine with all the B/G devices I had, but when one wireless N device connected it would prevent the other devices from working, but when connected to my new router, it works perfectly - was just a clash between that particular configuration).

tkasier has provided evidence that indicates that at on at least one production board, by changing between Euler power and USB power, there was a severe deterioration in networking performance. And repeated this with another non pine64 device to demonstrate that this sort of problem isn't pine64 specific. Data is data. It only takes one piece of evidence to disprove a theory, and this data proves that the GbE throughput is not immune to low voltage conditions, thus should not be dismissed out of hand.

Software does make a different to networking performance on any of these SoC ARM boards - since the networking is CPU bound, if the CPU is not correctly clocked and the governor appropriately configured, networking will be slow. The debian pine64.pro image is incorrectly configured for optimum GbE networking out of the box - it is limited to sub-100M speeds when in 1000M (GbE mode). This is fixable by changing the cpu governor. This is with a sample size of one, but is 100% reproducible.

However, I don't believe auto-negotiation is affected by a software configuration, and if there is a failure there related to the mandatory syncing of clock speeds for GbE, then that is in the domain of the PHY, the pine64 build quality/design (maybe there is some crosstalk or some minimum separation of components has been compromised?) and the network environment (which includes the cabling, switches, routers, packet sizes, etc, etc).

So we may in fact have several reasons why 'the same' problem occurs... so until we can get some more conclusive evidence as to why GbE works in some cases, and doesn't work in others... we cannot rule anything out. Just because switching between micro USB power and euler bus power in one users case doesn't fix the problem, doesn't mean this problem does not exist... just means it is not the (sole) cause of GbE problem.

The goal now should be to minimise the different variables where possible, and if you get GbE working, you can then check if reverting back to x causes issues, or reverting back to y works also. You may find in your case, that the cable length is a factor, but it doesn't affect 4/5 other users. Another users says well, it works fine with xyz router/switch, but others don't have the same luck. This is where since if users are being asked to do a poll on if they are having issues or not, they should also be asked what can they change to add more data to the mix. i.e. my pine64 doesn't seem to be bothered by input power, heat, cable length, cable quality... once the linux distro is appropriately reconfigured for GbE speeds... it works reliably whatever I do it it to trip it up... but maybe the GbE PHY in the ADSL router I have is just that good (which is should be... the manufacturer is known for making reliable equipment!!).

That's enough of an essay, considering I'm probably preaching to people who are in full agreement. So, can we get back to the business of NOT saying that this or that isn't a problem, but instead focus on identifying what is.

That's easy...  because its a hardware problem; allow me to explain.

... hardware problems are almost always NOT precisely reprocudable , and almost ARE always  interpmittent, not only within their own environment but also across environments-- and particularly if the issue is border-line.

To be more precise, your board was not 'fixed' nor 'corrected' in longsleep's environment; he just knows how to tune the boards so that regardless of their condition they function better;  but, its still the same board, and it still is not functioning correctly.  I will absolutely guarantee that my bad board will NOT run in longsleep's environment , period (because my board is NOT border-line... at Gbe, it doesn't work at all !-- its not about tuning... its about non function.  It has a serious hardware flaw.

Just to be complete here, software problems (on the other hand) are almost always reproducable , on every machine , in all environments.  If you do x, y, and z the software will fail like such and so !  Also, if you make a software correction (on all boards) then the problem ceases to exist on all boards.  If the problem is environmental, then the problem follows the environment (for all boards). 

We have the unique situation with my boards in that one of them works perfectly (GbE) and one of them does not work at all (GbE); the problem does not follow the software, and the problem does not follow the environment !  In fact, the environment that I created for testing is perfect-- honestly , there is no better environment on earth to test these boards than in my lab.  One of my boards works flawlessly, and the other one does not work at all.  The conclusion is 'conclusive' !  This problem is a hardware flaw (probably manufacturing flaw, as apposed to design flaw) on the boards themselves.

[MarkHaysHarris777]

<snip>

That's enough of an essay, considering I'm probably preaching to people who are in full agreement. So, can we get back to the business of NOT saying that this or that isn't a problem, but instead focus on identifying what is.

I respectfully disagree with your viewpoint, as well your approach to hardware|software diagnostics;  however, if your approach will solve this problem quickly, perhaps you might spend more time solving it, and less time writing essays.

[waldo]

<snip>

That's enough of an essay, considering I'm probably preaching to people who are in full agreement. So, can we get back to the business of NOT saying that this or that isn't a problem, but instead focus on identifying what is.

I respectfully disagree with your viewpoint, as well your approach to hardware|software diagnostics;  however, if your approach will solve this problem quickly, perhaps you might spend more time solving it, and less time writing essays.

Harsh mark, and uncalled for ..... but hey ... you're the dictator moderator ....

[MarkHaysHarris777]

<snip>

That's enough of an essay, considering I'm probably preaching to people who are in full agreement. So, can we get back to the business of NOT saying that this or that isn't a problem, but instead focus on identifying what is.

I respectfully disagree with your viewpoint, as well your approach to hardware|software diagnostics;  however, if your approach will solve this problem quickly, perhaps you might spend more time solving it, and less time writing essays.

Harsh mark, and uncalled for ..... but hey ... you're the dictator moderator ....

Good morning waldo,  always a pleasure...

My grandmother used to tell me when I was young, "You know you have won the argument when they call you names".

waldo, I am a professional engineer, have worked with IBM for almost thirty years, and have extreme experience in electronics hardware|software diagnostics; not only professionally , but as a hobby. I am an amateur radio operator and I have built my receivers and transmitters; most of my computer add-ons I build myself, and I never have non working systems--- not ever--- no brag, just fact.

If you want to call me names it will not affect me at all.  I'm still going to help you solve this problem, and I'm still going to add my abilities to the community for mutual benefit.  But I warn you strongly, don't call anyone else names....

[clarkss12]

As I have posted before, I ran into the same problem on one of my Android boxes, two or three years ago.  The Ethernet would connect but transfer rate was the same as this box.  I replaced a new 100ft cat 6 Ethernet cable with another new cat 6 Ethernet cable, still did not help.  Purchased another 8 port unmanaged Ethernet switch, that did not help.  Manufacturer updated the firmware and problem went away.

The Ethernet connection WILL work with Linux, but not Android or Remix OS.  The Pine people need to get after Allwinner and get the correct drivers.

I have a Remix Mini that has the same SoC as this Pine board, and it does not have an Ethernet problem.  Right now my Pine board is in a drawer, where it usually stays.  Pine NEEDS to get this problem corrected, NOW.  This has gone on for WAY too long!!!

[clarkss12]

I don't know chit about how Ethernet works, but I am sure it is not a hardware problem, just from my personal experience. Also, why does the Ethernet work with Linux, but not Android or Remix OS???

[MarkHaysHarris777]

I don't know chit about how Ethernet works, but I am sure it is not a hardware problem, just from my personal experience.  Also, why does the Ethernet work with Linux, but not Android or Remix OS???

Your experience is obviously lacking.

Ethernet does work with Android and Remix. My Android playdesk has been ethernet connected since installation-- ssh, scp, playstore, all of it works just fine over ethernet.  

Your very first clause of this post (about not know 'chit' about ethernet) is why you don't understand that this issue is hardware based (flaw in the board itselft).

[waldo]

I don't know chit about how Ethernet works, but I am sure it is not a hardware problem, just from my personal experience.  Also, why does the Ethernet work with Linux, but not Android or Remix OS???

Your experience is obviously lacking. You're wrong in my opinion

Ethernet does work with Android and Remix. My Android playdesk has been ethernet connected since installation-- ssh, scp, playstore, all of it works just fine over ethernet.  Gigabit Ethernet works on a per board basis, some boards work perfectly fine, others do not.... If you can live with only having 100mbit/s for now, you can check this thread: http://forum.pine64.org/showthread.php?tid=1739. Linux has commandline tools to set the rate to 100mbits, android hasn't.

Your very first clause of this post (about not know 'chit' about ethernet) is why you don't understand that this issue is hardware based (flaw in the board itselft). Did i say that out loud ?

TRANSLATION IN RED


Meanwhile, has anyone tried this master autoneg patch from http://lists.denx.de/pipermail/u-boot/20...49734.html
I can't apply this myself, but keep thinking its worth a shot...