Jump to content

Le Potato Ethernet Problems

NinjaKitty

By NinjaKitty
in Libre Le Potato

 Share

Recommended Posts

TonyMac32

TonyMac32

Posted
Posted

@Da Xue, I can't find where that would go in stmmac_main.c, I would guess there are some other patches leading up to that one? 

static void moniter_tx_handler(struct work_struct *work)

does not appear to exist in any kernel I can find.

<
TonyMac32

TonyMac32

Posted
Posted

Thank you for the clarification, @Da Xue.

 

I'm currently testing out the 4.14 mainline patchset, so far I've been pinging the board for 12 hours and am now (30 minutes) running an SSH from it without the ethernet going down.  I'm going to add an SSH into the board as well and let it run something or other that keeps the network traffic flowing.

 

[edit]  2 hours with a self-refreshing webpage and an outgoing and incoming SSH session display "top" and no network drops. 

[edit 2] I added an audio stream to the mix and it proved to be too much, I lost connectivity with the device.

 

Igor

Igor

Posted
Posted
16 minutes ago, Andro said:

How does one obtain this patched image?


Since the nightly building is still on hold, you need to make one. I'll try to make one later if you can't build it.

reblair

reblair

Posted
Posted

I see the network dropping while testing for cifs support on the lepotato.  I'm using a build meson64 next 4.14.5 with the cifs module added in the config, but I saw similar lockups with the 4.14.2 release (which had no cifs.ko to test).  The interface loses its IP after heavy usage.  Has the AMLOGIC patch (or the equivalent) already been applied or is there a patch out there for this problem?

 

I also notice that the MAC for this device is random unless it is set manually in /etc/network/interfaces with the hwaddr directive.  Is this normal?  I have never seen this behavior on a number of raspberrypi's, an odroid nor on a bananapi.  

TonyMac32

TonyMac32

Posted
Posted

The Amlogic kernel is significantly modified from mainline, so the workaround kernel patch mentioned earlier doesn't apply to mainline, we'll have to wait for BayLibre to address it.  

 

 

TonyMac32

TonyMac32

Posted
Posted
20 minutes ago, Da Xue said:

BayLibre says they're close to a fix. It's an issue with EEE capability being mis-detected.

 

Thank you for the update, I saw the activity in the lists, I should be able to try the patches out soon to see how they work.  For the short term I've been using a wifi dongle.  

1
Da Xue

Da Xue

Posted
Posted
25 minutes ago, TonyMac32 said:

 

Thank you for the update, I saw the activity in the lists, I should be able to try the patches out soon to see how they work.  For the short term I've been using a wifi dongle.  

Awesome, thanks! I still haven't decided if they should do a gigabit allwinner board called Helion.  The other thing is a S905X IoT/SOM board with LPDDR3.

reblair

reblair

Posted
Posted

I'm happy to test any patches.  I can reliably hose the network either by running kodi or tarring up data off one of my shares.  In general other activity is very stable.

TonyMac32

TonyMac32

Posted
Posted

After applying https://github.com/libre-computer-project/libretech-linux/commit/10e57db5d30693ef4e08d0611e62c0d61a97e419  I still got a link hang/failure relatively quickly, however after disabling/re-enabling networking I then streamed a bunch of video and music and am still up and running. (Hung twice more while typing this).  

 

This has been a "forever" problem with GX and GXL it would seem, 

http://rglinuxtech.com/?p=1831

 

The author of the above link disabled flow control and seems to have "fixed" it at the expense of performance.  I am going to test it's effectiveness (FAIL), since a fix may be some time, as the phy doesn't sound amazingly well documented.

Da Xue

Da Xue

Posted
Posted

I thought the first merge was a commit. Can you point me to the test scenario or script? I just built an 4.14.5 image with all the stuff built in.

TonyMac32

TonyMac32

Posted
Posted

I have been using the device as a desktop replacement for about a week, so I just unplugged my Wifi and went straight to ethernet-only, the connection went down in a matter of minutes while streaming videos on Youtube.  I switched to audio streaming and web browsing to the same result.

 

[EDIT]

 

It stuck out to me that this patch appears to address link negotiation problems (good, we don't want those either).  The issues I've seen (and seemingly the others in this thread) revolve around losing functionality after link is established, so potentially an entirely separate issue.  

TonyMac32

TonyMac32

Posted
Posted

@Da Xue I'm looking into some mdio errors I'm getting at boot, I'm not certain the PHY driver is being loaded, of course how ethernet works becomes a question, unless the meson8b-dwmac platform driver  <--- loaded because Le Potato --> Meson GXL --> Meson GX "compatible" device tree declaration is using a generic driver (which appears to be about 90% correct given the gxl driver, most of it being "genphy_x":

  

static struct phy_driver meson_gxl_phy[] = {
	{
		.phy_id		= 0x01814400,
		.phy_id_mask	= 0xfffffff0,
		.name		= "Meson GXL Internal PHY",
		.features	= PHY_BASIC_FEATURES,
		.flags		= PHY_IS_INTERNAL,
		.config_init	= meson_gxl_config_init,
		.config_aneg	= genphy_config_aneg,
		.aneg_done      = genphy_aneg_done,
		.read_status	= meson_gxl_read_status,
		.suspend        = genphy_suspend,
		.resume         = genphy_resume,
	},
};

I will take a closer look.

TonyMac32

TonyMac32

Posted
Posted

Last bit of Info:

 

Compiled it without it being a module, verified the phy driver is being loaded, overlooked "Meson GXL Internal PHY 0.e40908ff:08".  Problem persists. 

[ 1458.180440] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 1458.251686] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=POLL)
[ 1458.263053] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW
[ 1458.263447] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 1461.315784] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[ 1461.315842] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

The Ethernet network simply hangs, no data moves but the link claims to be up.  Disabling/re-enabling networking entirely renegotiates as you see above.

 

 

JeromeB

JeromeB

Posted
Posted

Hi Guys,

There was a couple of issues around ethernet on gxl. This may have been the source the confusion.

1) LPA Corruption: Sometimes the LINK PARTNER Advertisement is not correctly sampled: When this happens, you see the link being negotiated at 10Mbps/Full or 10Bmps/Half instead of 100Mbps/Full
This is fixed by https://github.com/libre-computer-project/libretech-linux/commit/04e76dadce3ec09bbefb45fde95580d217fc5c38. I have pushed it to libretech repo because the patch has been accepted by the net maintainer.

It will eventually end-up it linux stable and future kernel releases

2) Net hangs: There are lot of ways to reproduce this issue. What worked best for me was to wget a small file (2kB) in a loop. Downloading large file in background helps.

The problem is coming from EEE and Low power Idle. It should not be enabled or supported by the PHY. However, when reading the related registers, you get 0xFFFF.
This is interpreted as "Yeah ! everything is supported ! go ahead !". The (proposed) fix is to prevent stmmac from trying to activate EEE in RMII mode : https://patchwork.kernel.org/patch/10092657/  
Patch is still at RFC state, which is why I did not push it (yet) to the libretech repo. It should be safe to apply though.

Hope this helps

Cheers

 

 

1
TonyMac32

TonyMac32

Posted
Posted

Thank you @JeromeB, I was looking at your patches this morning (EST Detroit), was going to try them out in a few hours.  I also saw you adding yourself to the "Blame List" for the driver.  :lol:

 

Thanks again!

TonyMac32

TonyMac32

Posted
Posted

@JeromeB understood.  Patched, tested, no negative consequences, and so far no hangups either.  

 

Is the recent series slated to make it into a 4.14? 

 

[edit] streaming video, 3 ssh sessions (one with X-forwarding), and moving files around in the background and no issues.  

 

Had some time, and added the series of phy adjustments as well to our 4.14.y build, everything is working quite nicely.

  

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.14.7-meson64 (root@builder) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #38 SMP PREEMPT Tue Dec 19 01:16:29 EST 2017
[    0.000000] Boot CPU: AArch64 Processor [410fd034]
[    0.000000] Machine model: Libre Technology CC

...

[   17.562193] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=33)

 

2
JeromeB

JeromeB

Posted
Posted
5 hours ago, TonyMac32 said:

 

Is the recent series slated to make it into a 4.14? 

The LPA fix is already in 4.15-rc4, it will eventually be backported to the stable tree.
If everything goes well, it should the same for the EEE fix.

The rest (clean-up and improvements) are not fixes. Those won't be picked up by stable linux. Unless there is real need for them, which I don't see at the moment, I won't apply them libretech v4.14. It is better to follow stable as much as possible.

NinjaKitty

NinjaKitty

Posted
  • Author
Posted

Thanks guys for the updates.

 

Is a build with the EEE fix available on any downloadable build at the moment? I would like to try it myself and see if I'm able to do what I originally intended to do before I opened this thread.

 

Igor

Igor

Posted
Posted
1 hour ago, NinjaKitty said:

Thanks guys for the updates.

 

Is a build with the EEE fix available on any downloadable build at the moment? I would like to try it myself and see if I'm able to do what I originally intended to do before I opened this thread.

 

Yes. In our beta/nightly repository, updated a few moments ago.  Just do apt update & upgrade


Wrote on mobile

1
NinjaKitty

NinjaKitty

Posted
  • Author
Posted

Is there a build number that I can confirm that I updated to it?

 

Also want to mention that it feels bad when you're trying to download a patch for your ethernet to not crash and ur ethernet crashes haha.

 

TonyMac32

TonyMac32

Posted
Posted
1 hour ago, NinjaKitty said:

it feels bad when you're trying to download a patch for your ethernet to not crash and ur ethernet crashes

:P

uname -a

Linux lepotato 4.14.7-meson64 #51 SMP PREEMPT Tue Dec 19 12:33:49 CET 2017 aarch64 aarch64 aarch64 GNU/Linux

Is what mine says after update.  

NinjaKitty

NinjaKitty

Posted
  • Author
Posted

With the 4 potatoes I have, I (after many tries) successfully updated all 4 of them. I ran the docker install script on all 4 (which usually would crash 2 or 3 of them, but didn't crash.).

 

I'm running some services on them, will probably add some more tonight and also start executing traffic through them (they don't have much traffic as of right now.)

 

So far it seems fixed. However, I did notice that the internet speed feels slow. I'm not sure if this is a potato problem or the servers I"m downloading from, so I'll try running some iperf tests later tonight also.

 

Edit: I also want to mention that 

for some reason, it worked fine when I rebooted my first potato The other potatoes required an ifdown; ifup before being able to use the internet. Probably will look into that more again too.

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept