Kinda upset at the lack of response to GBe issues

[pfeerick]

I do this with my software all the time.  I write it; and I hope that you use it, and even find it useful. But don't come back to me with any complaints, or law suits, or whining, nor anything else--- because my fine print in the header of all of my software says, this is not guaranteed to be useful for anything (the language is rich, and full and it takes three paragraphs to say it, but it all boils down to "use my stuff at YOUR OWN RISK ENTIRELY"

Yes, that is true. HOWEVER, in the case of software, there is a clear place to sign your agreement to the contract which you are entering into (which is what a EULA actually is - a contract that you agree to be bound to). In the case of software, you digitally affirm the contract by pressing the 'I Accept/Agree/' option. Nowhere on the packaging of the pine64 does it indicate that breaking of the seal signifies acceptance of any term. And in contracts cases where the terms and conditions have not been clearly brought to the attention of the intended signee, the majority fail, as insufficient notification of the terms of a the contract is deemed equate to the contact being null and void. 

If you read the back of the box very carefully you will note that it actually does in fact say what I'm telling you--- " ... does not warrant that the products are error free or will function without interruption".  That sentence right there says, (in so many words) "We do not warrant that GbE will work accurately (without error), nor that it work without interruption"

Partly treated with above, but I will again reiterate that consumer legislation can and does render this statement void. I'm not versed in US law (and more specifically, California's), but I find it hard to believe that you have no consumer protections in place to prevent all warranty conditions from being stripped. And we have not been talking about 100% reliability, we have been talking about ANY usability - which is completely different! Additionally, that warranty is incomplete to say the least - it has reference to terms that are not present, such as the time period that the warranty period is valid for - as it is specifically mentioned, but not defined. Uncertainly such as this also breaks contracts, as any ambiguity leads to the parties not being of a like mind in all things (ad idem). For example, the very first line reads "Except for the extent set forth above in this limited warranty"... um... this is the top line? So whilst the sets out, clearly omitted is what IS covered! And saying that the word was meant to be below also makes no sense, as again, if you're talking about what isn't covered, then what IS?

The EULA is very specific, and yes, it will fly in court... in the United States. (it is standard language and it flies all the time, in the United States).  And here's the deal... like it or not... you're supposed to read that agreement before you open the seal on the box.  The truth is that most people are so excited to open the box, they don't even know there is an agreement under there !   I've tested this many times now... I have not found even ONE person yet, that new the EULA was on the bottom of the box... true story.  If you knew, you are the exception.

lol... I'm unlikely to be the exception... the box was upside down when I opened it... but there is a difference between knowing it's there, remembering it's there, and understanding what it means. And language like that usually flies only because people don't have to resources to fight it in court. Not because it is right/legally valid. 

However, you are still missing the point entirely. I was pointing out that a company that tried to rely on legalise like this, even if they managed to make an argument that is was legally binding, would become a very broke company indeed, as they would be boycotted by the community as a company that just takes your money and runs. Unsurprisingly, they haven't been relying on this, and when you report it to be faulty in some major manor, a replacement has been sent out. 

Now, can we get back to the matter at hand, as this really isn't what this thread is about. If you really believe that this so-called EULA is worth anything more than the cardboard it is printed on, I'm happy to argue the point further, and throw several hundred pages of case law at you in another thread devoted just to that. 

[clarkss12]

Perhaps I am missing something with your poll.  My Ethernet port works in Linux, but not in Android or Remix OS.  That is not an option on your poll???  Or is this discussion only for Linux people??

[MarkHaysHarris777]

Perhaps I am missing something with your poll.  My Ethernet port works in Linux, but not in Android or Remix OS.  That is not an option on your poll???  Or is this discussion only for Linux people??

Excellent point.

... we are hoping that folks inclined to do so would take the poll (supposed to be OS independent) and then in the body of their post indicate the specifics of their use case; for instance (numbers) and anything else useful , like for instance the OS of choice.

The poll is for everyone using the PineA64, regardless of OS, and regardless of use case.  We're looking for patterns and deliberately are not trying to lead or guide the survey.

Thanks for the good question

---

@ pfeerick

... I will again reiterate that consumer legislation can and does render this statement void. I'm not versed in US law (and more specifically, California's), but I find it hard to believe that you have no consumer protections in place to prevent all warranty conditions from being stripped. 

However, you are still missing the point entirely. I was pointing out that a company that tried to rely on legalise like this, even if they managed to make an argument that is was legally binding, would become a very broke company indeed, 

You have so far been discussing this issue as though Pine Inc were Ford Motor Co. 

... Pine Inc is NOT providing a product for consumers in the startup. (this is not about consumer protection)  Pine Inc asked for money to form a startup...  they are specifically NOT providing a product in the kickstarter... they are asking for investors in a product , the reward for which is a sample(s) of the prototypes. By the vary nature of the transaction consumer protection legislation is mute, because everyone up front knows that this prototype is new, is experimental, has never been commercially tested nor verified, and that (by the nature of the formal agreement under the label) the prototype is NOT WARRANTED for anything, for any period of time, at all, period.  And the labeling says just that.

Comsumer boycott does not come into play either... just the opposite actually, investors have been asked to invest in something that does not (as yet) exist, and when produced is experimental, and in fact may not work... the investor by definition is making and taking a RISK.  (consumer protection laws do not come into play with that either).


The main point in this argument is that Pine Inc was not producing a product for the community; rather, they were producing a company who was offering a prototype for the opportunity to invest in a new venture-- the rewards of which (the prototype) would be provided (as the agreement states) soley on an "as is" basis.  You take it or you leave it, but its not warranted for anything, for any time period, at all. The whole point is that there IS NO WARRANTY on the prototypes produced by a startup company.

Once the company is established , and the products are tested , things change. (but not for the investors of the startup).

Further, the role of the investors (pertaining to the prototypes) is to help (cost free) with the testing of the product prototypes!  The investors get the honor of partaking in that product testing.  Now Pine Inc knows that it has an issue with the ethernet port;  thank you all very much.  Investors are not consumers, they are investors, and they subsequently become beta testers...  again, consumer product protection legislation is mute on this also.

[amc2012]

I did mean that most people are not using it; and by most people I mean that most 'people with pine boards' are not using GbE, and that most 'common people' on the Internet are not connecting to the Internet with GbE either. GbE is not a common Internet standard used by most people.  We have 38,000 of these Pine64 boards in the wild and very few are reporting the GbE problem. Almost all of my machines connect with wifi, and most people connecting on the Internet are connecting via wifi.

I'd still be careful about making even that statement, Mark. If you mean most people with pine boards aren't using the ethernet period.... then there is a fair chance of that, depending on how many also bought the integrated wifi, and how many are using USB wifi adapters. It might be a good point to remind that (as stated on the kickstarter campaign page) that the Pine A64+ is the only one that supports GbE - the Pine64 (BASIC) only supports 10/100 Mbps ethernet. So that is another factor that could be considered. However, if you mean people with ethernet not using GbE... that is a curly one at best. Consumer grade GbE stuff has been been mainstream for several years now.

That is the argument I was making as well. Gigabit Ethernet is pretty well-established at this point. There should be "no surprises" by this time, as the spec has LONG been written, and the technology has been included in just about every desktop mainboard for I'd guess a decade or more at this point. The whole reason I bought the PINE was for the gigabit port. Otherwise, I would have been more than happy to continue along with my RaspberryPi 2. 

So in other news, in my quest to get my GbE port working on this thing, I had a little excitement today, and then a lot of disappointment.

My Netgear managed Gigabit switch came two days early. So imagine my surprise when I went to configure it and the only options are Auto, Disable, 10M half, 10M full, 100M half and 100M full. So of course I upgrade the firmware hoping to see that extra 1000M half and 1000M full, and no dice. So I contact Netgear support and ask them, "where is the 1000M manual setting?" 

Their answer? It's not needed. That's what Auto is for.

SMH. FML.

You've got to be kidding. So I ask, are there ANY Netgear switches that allow you to force 1000M through manual selection?

The rep goes away for a long time. Comes back with the answer, "it appears not."

This is the second time I have bought a Netgear piece of equipment in the last three or four years that had some stupid setting that I wasn't able to select. The other was a router that didn't allow me to do something or other, I forget. 

So, at this point I'm wondering if I should sink another $30-40 into another switch or just see if we can get somewhere on the poll. Guess I'll try that for now. Grrrrr. Never again, Netgear. What a shame. I still have one of those old 16(?) port metal Netgear unmanaged switches humming along in the wiring closet in the basement. Sad they seem to be dumbing down and consumer-i-fying everything now.

---

I just wanted to say thank you, Mark, for adding the poll, and to whomever for moving all these threads into its own section on these boards. It's good to see all the issues in one place so hopefully we can all get to the bottom of this.

[pfeerick]

You have so far been discussing this issue as though Pine Inc were Ford Motor Co. 

... Pine Inc is NOT providing a product for consumers in the startup. (this is not about consumer protection)  Pine Inc asked for money to form a startup...  they are specifically NOT providing a product in the kickstarter... 

Yes and no. I have been discussing this as if Pine Inc were like any other company, for purchases from the web store. I believe I mentioned before that Kickstarters were not covered by any consumer protections/forced warranties (as they are rewards for the investment, not a purchase). My apologies if this was not mentioned prior, but I thought I had mentioned that prior. For crowdfunding rewards, the disclaimer on the box isn't even worth the cardboard it is printed on as there is no warranty, express or implied, to limit! 
However, for purchases this is a different thing. The reality of the situation is, though, unless you bought a bucket load of the boards, you would probably just write them off rather than pursue legal action, return for investment ratio just doesn't warrant it. Doesn't mean it is legally or morally right.

[amc2012]

Don't know if this has been posted before, but perhaps it's relevant?

https://patchwork.ozlabs.org/patch/602067/

This patch introduces CONFIG_RTL8211X_PHY_FORCE_MASTER. If this define is set, RTL8211x PHYs (except for the RTL8211F) will have their 1000BASE-T master/slave autonegotiation disabled and forced to master mode.

This is helpful for PHYs like the RTL8211C which produce unstable links in slave mode. Such problems have been found on the A20-Olimex-SOM-EVB and A20-OLinuXino-Lime2.

From the poll thread, it looks like so far we all have the "Green" RTL8211E. Wonder if the uboot could specify FORCE_MASTER when that chip is detected? Then we could do some testing.

The drawback is that it seems ports forced to MASTER will not connect with other ports that are forced as well, and you don't want this applied to chips that don't need it forced. Forcing MASTER would help those of us with one PINE in our environment, but for those going PINE to PINE, it wouldn't work. Either way, I'd commit to test any upcoming potential resolutions, even if my particular issue was solved since I only have one PINE.

UPDATE: There is also this, from http://linux-sunxi.org/Ethernet:

For reliable Gigabit networking (1000Mbit operation), several sunxi devices require an important tweak that adjusts the relative timing of the clock and data signals to the PHY, in order to compensate for differing trace lengths on the PCB (details). Among others, this includes Banana Pi/Pro, Cubietruck, Lamobo R1, pcDuino3 Nano and Orange Pi/Mini. Recent mainline U-Boot uses CONFIG_GMAC_TX_DELAY to initialize these devices accordingly. If a necessary GMAC TX delay isn't set, then GBit Ethernet operation might be unreliable or won't work at all. 10/100 Mbit/sec negotiation is unaffected, so misconfigured devices could actually work (faster) when connected to a Fast Ethernet port instead of a GBit Ethernet port.

I know we've already done testing with TX_DELAY, but perhaps this is hitting that in a different area (GMAC delay)? I dunno. I'm not a linux expert, just trying to dig some stuff up for those who are. But they might already be aware of all this.

[benjanyan]

Having intermittent issues with my PINE64 2G Ethernet as well on 1Gb.

It works most of the time... but sometimes it's really slow on the tx side. I've also seen it unable to acquire an IP address automatically. Swapping ports on my router seems to kick it into life again usually. It's okay at this precise moment but it'll probably throw a wobbly at some stage. I'll try and post more info when it is having one of its moments.

Code:

yuki_n@aoba:~$ uname -a
Linux aoba 3.10.102-2-pine64-longsleep #66 SMP PREEMPT Sat Jul 16 10:53:13 CEST 2016 aarch64 GNU/Linux
yuki_n@aoba:~$ sudo ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 36:c9:e3:f1:b8:05
         inet addr:192.168.20.7  Bcast:192.168.20.255  Mask:255.255.255.0
         inet6 addr: fe80::34c9:e3ff:fef1:b805/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:5666217 errors:0 dropped:0 overruns:0 frame:0
         TX packets:6714105 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:6494935317 (6.0 GiB)  TX bytes:6641734676 (6.1 GiB)
         Interrupt:114

yuki_n@aoba:~$ sudo ethtool eth0
Settings for eth0:
       Supported ports: [ TP MII ]
       Supported link modes:   10baseT/Half 10baseT/Full
                               100baseT/Half 100baseT/Full
                               1000baseT/Half 1000baseT/Full
       Supported pause frame use: No
       Supports auto-negotiation: Yes
       Advertised link modes:  10baseT/Half 10baseT/Full
                               100baseT/Half 100baseT/Full
                               1000baseT/Half 1000baseT/Full
       Advertised pause frame use: No
       Advertised auto-negotiation: Yes
       Speed: 1000Mb/s
       Duplex: Full
       Port: MII
       PHYAD: 0
       Transceiver: external
       Auto-negotiation: on
       Link detected: yes
yuki_n@aoba:~$ iperf -c mashiro
------------------------------------------------------------
Client connecting to mashiro, TCP port 5001
TCP window size: 22.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.20.7 port 51133 connected with 192.168.20.6 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   611 MBytes   512 Mbits/sec
yuki_n@aoba:~$

The only interesting thing I've noticed is that my router (Asus N56U running Padavan's firmware) reports FCS errors (whatever they are). It's done this on multiple ports that the PINE64 has been connected to whereas the other two plugged into another switch and modem report none. I dunno if this is relevant to your efforts at all... I did of course blame the cable before the forum made me aware of the issues with the PINE64 and Gb ethernet. Swapping it around with a couple of others had the same results... worked for a bit and then threw a wobbly a day or two down the line.

Code:

Port Link            : 1000 Mbps, Full Duplex, FC OFF

MIB Counters
----------------------------------------
ifInOctets            : 4483548236
ifOutOctets            : 73064230
etherStatsMcastPkts        : 36667
etherStatsBcastPkts        : 4463
etherStatsFragments        : 0
etherStatsDropEvents        : 0
etherStatsUndersizePkts        : 0
etherStatsOversizePkts        : 0
etherStatsCollisions        : 0
dot3StatsFCSErrors        : 6840
dot3StatsSymbolErrors        : 0
dot3ControlInUnknownOpcodes    : 0
dot3InPauseFrames        : 0
dot3OutPauseFrames        : 0

Compared to another port connected to another Gbit switch in my flat through 15m or so of CAT6. I noticed we have "FC TX/RC" here.

Code:

Port Link            : 1000 Mbps, Full Duplex, FC TX/RX

MIB Counters
----------------------------------------
ifInOctets            : 304624413
ifOutOctets            : 9667946372
etherStatsMcastPkts        : 126449
etherStatsBcastPkts        : 14319
etherStatsFragments        : 0
etherStatsDropEvents        : 0
etherStatsUndersizePkts        : 0
etherStatsOversizePkts        : 0
etherStatsCollisions        : 0
dot3StatsFCSErrors        : 0
dot3StatsSymbolErrors        : 0
dot3ControlInUnknownOpcodes    : 0
dot3InPauseFrames        : 0
dot3OutPauseFrames        : 0

My main use of the PINE64 is a Samba server sharing an attached USB HDD so I tend to notice the poor throughput.   Doesn't look like there's a poll option for "works most of the time but not all ways" but I'll add the info to it and try to help to the best of my ability (not much to speak of). Let me know how else I can help.

[MarkHaysHarris777]

Last night I finally received my switch (unmanaged, TEG-S81g by TRENDnet) and was able to do some testing.

... I got my two boards working GbE once I did the following things :

1) set the mac address to match the label on the bottom of the board;  the important part is the prefix, which for all three of my boards is  00:06:dc  (the local bit must be set off, or no worky)

2) disabled ipv4 by adding the following to  /etc/sysctl.conf
# uncomment to disable ipv6
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.io.disable_ipv6=1

3) shutdown the  avahi-daemon    with  sudo systemctl stop avahi-daemon

I tested with ssh, scp, and iperf.  Something else very interesting is that when debian is the client and ubuntu is the server things improved A LOT, but when ubuntu is the client and debian is the server things slowed some.  Also, as the RTL8211E gets hot, it slows down; needs a heatsink.

I think we're at the point of acknowledig that the RTL8211E works, and now its a matter of timing (buffers, queues, irqs, Tx and RX delays).   jonsmirl points out that setting the Tx and Rx delays requires a scope, to get them to match; its just too twitchy to get trial and error.

Both Needles and Erol have made this work similarly. (continuing to test)

---

edit: PS   I discovered the difference;  the cat6 cable to one pine was short, the other long.  I will adjust this to both 'short cat6' 1M  and post results tomorrow.

[pfeerick]

Last night I finally received my switch (unmanaged, TEG-S81g by TRENDnet) and was able to do some testing.

... I got my two boards working GbE once I did the following things :

The big question here then is... did GbE NOT work until you did all of this, and if so, do you have to do all three (set mac, force IPv6, shutdown avahi-daemon)? Is setting the mac address enough? Since you have mentioned IPv6 here... I half wonder if it's worth turning that off on my router to see if I can get the pine64 to baulk at being a well-behaved GbE device!  

Also, since people may be unfamiliar with how to set the MAC address on the pine64 (and that you can in fact change it!!!), I refer you to longsleeps recent post on exactly that!

[amc2012]

Yes, I had gone to try longsleep's fix (he wrote to me this morning), but I am one of the lucky ones who does not have a MAC address on the bottom of my PINE. Only have a serial #. So no dice for me.

When I was MarkHaysHarris777's post above though, I figured I might try replacing the first part of the MAC specified in Uboot with what he listed there (since he said all three of his boards started with that). Course, that didn't work. Same connectivity issues as before.

So I am still here with non-working GbE.