opi zero ethernet behaviour

[caplam]

Hello every one,

 

My first post here i'll try to be clear but english is not my mother langage.

I bought a couple of opi zero with usb expansion board and a case.

I needed small devices able to run a linux daemon and control a bluetooth LE device. They are used as antennas in a bluetooth mesh network. The orange pi zero seemed to be a good choice.

I first installed the opizero with armbian 5.24 debian version. Unfortunately I was unable to use bluepy lib. It was the same with the xenial version.

Another user of the bluetooth advertisement plugin told me to use last firmware (5.25) and upgrade to 4.x kernel. I was then able to use bluepy lib.

I moved the opi zeros to their definitive place. They were plugged in an apple airport extreme. When i plugged them in my switch (hp 2810-48G)  i was unable to get them connected. I did multiple tries even with the 3.x kernel but no luck.

It was ok with the airport and a dlink basic poe switch (not using poe feature) but not in the hp (L2 switch).

 

I finally found that when changing port configuration from auto to 100 full duplex it was ok.

Airport extreme and dlink switch are quite basic and negotiation of the port config is automatic but it seems to work.

However it appears that opi zero is unable to negotiate with the hp switch. You have to set it up manually.

Maybe somme things could be changed in the driver configuration i don't know. Despite i have a beard i'm not a gifted linux geek.

Reading this forum or orange pi one, it appears to me it could be an interesting news.

 

[caplam]

Searching in the forum i found some posts about ethernet subject in development section.

I didn't know about ethtool.

It seems that both my opizero are stuck at 100HD. Doesn't seem to be unusual as i run nightly build.

However the negotiation problem appeared also when using armbian 5.24 with debian jessie legacy 3.4.113

[SomeArmbianForumUser]

I needed small devices able to run a linux daemon and control a bluetooth LE device. They are used as antennas in a bluetooth mesh network. The orange pi zero seemed to be a good choice.

 

Why choose the orange pi zero for this? It does not have bluetooth on board.

[caplam]

I needed a small device with wired and wireless connectivity, with poe support, with a case available, able to run a linux distro, cheap. I think the opi zero meet these requirements.

Someone on the board (not here but on the jeedom board) mentionned the pi zero.

I gave it a try. For the bluetooth i only needed to plug a cheap bt4.0 dongle. It's dedicated to ble scan.

I probably will try also to plug another bt dongle to manage voice advertisement with a BT speaker and pulse audio.

Ok i read too fast the specs and the poe implementation is really crapy as i don't plan to solder anything on the board. I think i'll use a passive adapter to output power from the switch with an microusb plug.

[tkaiser]

I think i'll use a passive adapter to output power from the switch with an microusb plug.

 

Can you please elaborate how you power your Zero today (especially length and AWG rating of the cable used) and how you diagnose the 'negotiation problem' (do you use a serial console attached to the appropriate pin header or do you interpret random behaviour?)

[caplam]

I use an amazon adpater. It's a 22awg cable. I measured 5.35V with the pi zero running (but without the expansion board plugged).

For now i don't use a poe adapter.

I've no serial console attached so it's not a real diagnose.

I've noticed that both of my pis didn't get network connection when plug in any port of my switch (trough my home cables or directly on a switch port with a patch cable).

I ssh in the switch and saw that the link is down.

When i configured the switch with a 100FD link in place of autoneg the link came up. As soon as i go back to autoneg the link is down. Notice that even if the link is set to 100FD, ethtool tells me that the link is in fact 100HD; the switch tells me it's 100FD.

 

I tried with 2 other switch: an airport extreme (2013) and a dlink DGS1008P. These switches don't offer any settings for link negotiation. Plugged to these both the pi's obtain a link.

 

So even if it isn't a true argumented diagnostic it seems to me that there might be a problem with negotiation.

If you need details i'll be happy to provide some but i'm not experienced in linux.

 

Edit: the power adpater i use is https://www.amazon.fr/gp/product/B00MTXC680/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1

So it's around 1.7m long and use 22awg wires.

[tkaiser]

The PSU looks ok but it would be great when you run a 'stress -c 2 -m 2' on the board and then measure voltage available at the Expansion board (pins) just to ensure you're not running in undervoltage trouble. I tested with Orange Pi PC a year ago and this one worked flawlessly with just 4.5V input voltage (though neither USB nor HDMI connected -- both ports require a lot more than 4.5V as minimal voltage) but no idea about the Zero.

 

If I remember correctly almost all reports related with network negotiation problems (the half duplex issue) are reports from those H3 boards using shitty Micro USB for DC-IN. So I thought it might be worth a look whether we're not talking about power problems instead (also IIRC the Fast Ethernet PHY inside H2+/H3 needs 1.2V provided by some regulator and in case this regulator is not linear a drop in input voltage might affect networking negotiation).

 

BTW: Am currently also in France. We bought yesterday a rather expensive 5V/2A rated PSU at Carrefour and drive now back to return it. Death on arrival or let's better say the usual 'undervoltage under load' problem

[caplam]

For now i didn't do stress test but here are the tests i did.

I change the port switch configuration and then run ethtool eth0 to see what the pi understood.

switch config   Connection    advertised         link
auto            No            /                  /
auto-10         No            /                  /
auto-100        No            /                  /
auto-10-100     Yes           10H-10F-100H-100F  100H
10H             Yes           10H                10H
10F             Yes           10H                10H
100H            Yes           100H               100H
100F            Yes           100H               100H

in the advertised colomn i put the answer of ethtool : avertised mode by the partner.

Considering this i think there is a problem with full duplex. No way to run in full duplex mode neither at 10Mb/s nor 100Mb/s.

I don't how it works but it doesn't seem to be effective.

It was the occasion for me to log in my switch which i didn't do for months (years perhaps?). I saw that i had another port which had issues. I had crc alignment errors due to a duplex mismatch. The device in question is a beelink mini mxIII running libreelec (kszaq build 7.002). It seem to have trouble from time to time to stay in full duplex mode. But this device is always online and the link remains up.

 

I know i'm running a dev build but it's the only way for me to be able to use the bluepy lib.

 

Here is the driver info:

 ethtool -i eth0
driver: sun8i_emac
version: 00
firmware-version: 
bus-info: 
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

[tkaiser]

The sole purpose of the stress test is to check the quality of your PSU. If you experience voltage drops measured at the board that go below 4.6V then I would consider your problem 'entering power supply issue area' not worth any further look until board is powered differently.

 

Sorry for this answer but at least I will not waste any more time with reports about 'software issues' that might be just the result of underpowering (or the other well known problem -- please see my signature below).

 

And just for your information: the sun8i_emac driver in mainline kernel is to be replaced in the future since Theobroma devs discovered that the Ethernet implementation in H2+/H3 is 'stmac' with obfuscated registers so that the driver author had to throw his driver in the bin and is now working on a stmac variant. So bugs with either legacy driver (made by Allwinner) or mainline/dev sun8i_emac driver (made Correntin Labbé) won't be fixed anyway. If there's a real issue your only hope is sun8i_stmac sometimes in the future.

[caplam]

Thank you for your answer. I understand the need to do a stress test and I'll do it. 

It isn't a real issue for me as i don't have "high " network needs. In normal conditions my pi's have very light load (max 10% cpu) and a even lighter network load so it can run in half duplex mode. My point was only to report that but if the driver is to be replaced there's no need for further investigations.

Anyway i ordered a console cable which could be useful in the future.

I'll post here the result of stress test.

[caplam]

here are the results:

root@opizero1:~# stress -c 2 -m 2
stress: info: [1113] dispatching hogs: 2 cpu, 0 io, 2 vm, 0 hdd
stress: FAIL: [1113] (416) <-- worker 1117 got signal 9
stress: WARN: [1113] (418) now reaping child worker processes
stress: FAIL: [1113] (452) failed run completed in 86s

Before test under normal opération (10% cpu load) i have 5V at 5.25V (on the 13 or 26 pins header) and 3.3V at 3.35V

During test i have the same voltages.

 

edit : here is the the result of sudo armbianmonitor -u: http://sprunge.us/VKiF

edit 2 : I have another test which is running since 5 min and it's going on.

edit 3: I stopped the test after around 10min. It didn't report errors.

The first test fail seems to be a memory problem.

[hpapagaj]

Is there any workaround to the Half Duplex problem?

 

[   15.370334] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Half - flow control off

 

I can't connect full duplex.

[Igor]

6 hours ago, hpapagaj said:

Is there any workaround to the Half Duplex problem?

 

[   15.370334] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Half - flow control off

 

I can't connect full duplex.

https://forum.armbian.com/index.php?/topic/3267-eth0-stuck-at-half-duplex-orange-pi-zero/&do=findComment&comment=26212